March 2011 - Posts

TestDriven.NET defaults tests for code running on AnyCPU platform to be executed under 32-bit process by default. In order to change that, it has to be configured in VS through Tools –> Options –> TestDriven.NET –> AnyCPU Tests

image

Are you developing on Windows 7? Do you have your UAC turned off?

These are the questions I am asking developers that suddenly run into “unexpected behavior” with the code that used to work on their machines an now it doesn’t. When running Visual Studio .NET with elevated privileges you are the god. Literally. You can do anything – create virtual directories under IIS, manipulate file system where normally you’d be restricted, access anything you want – heaven for a developer. But the reality is that applications a lot of time ending up in environments that have UAC turned on. I do not expect a client system administrator to drop UAC on his server “just because our XYZ software was written in a God’s mode”. Good luck with that.

Yes, there are cases when you just have to elevate your privileges and nothing can be done about it. One scenario we ran into is compiling legacy VB6 application on a build server. And even for this scenario you do not drop UAC, you use the tools provided with the system. RunAs is one of those tools.

Bottom line – do not assume that running without UAC is a given thing, on contrary, assume it’s on and work out limitations with understanding of what are the options.

PS: RunAs case was actually simple – running once build scripts on the server manually with RunAs providing it with automated build service account and password. In order to persist the credential and avoid manual password typing, /savecred can be used. This will ensure that every time RunAs is executed with those credentials, no password prompts will be required.

I have ran into a problem while using NLog with web application – logs not created when application is deployed to IIS. Everything would indicate that this is permissions issue, except that I couldn’t figure out what account my web application was running under. Under II6 it was simple – IUSR, but with IIS 7 things have changed a little. Then I learned about Application Pool Identities. Very interesting, especially when locating an account DefaultAppPool resolves nothing, but IIS AppPool\DefaultAppPool does find DefaultAppPool. Either way, once I set write permissions for DefaultAppPool on the web application folder controlled by IIS, my problems were solved.

Moral of this story – when working with new things (IIS in this case), make sure you know read the manual. Just “clicking” it might be quite expensive (time wise).

This a great podcast from Deep Fried Bytes and Gary Short that is doing a great overview and explanation about Technical Debt to folks that are not developer, but managers.

Brand new project described by the author on his blog.

First reaction would be why?

Allow me present the problem: Application has regular WCF service and RESTful service implemented with ASP.NET MVC controller (we could implement RESTful service with WCF, but then the challenge would not exist…).

Invocation of RESTful service done with WebClient object requires requires URI. This URI is easy to store in appSettings of the configuration file. But then on the same client, to access WCF service, address is specified within the client endpoint configuration.

Solution is the following:

  1: <appSettings>
  2:     <add key="ServicesBaseAddress" value="http://localhost/Services/"/>
  3:     <add key="ServiceName" value="WCFService"/>
  4:     <add key="RESTServiceName" value="Controller/Action"/>
  5:   </appSettings>

WCF Client configuration:

  1: <client>
  2:   <endpoint name="WCFService" address="" binding="basicHttpBinding" bindingConfiguration="SomeService_Binding" contract="WcfBaseAddressSpike.Server.ISomeService">
  3: 	<identity>
  4: 	  <dns value="localhost"/>
  5: 	</identity>
  6:   </endpoint>
  7: </client>/

WCF dynamic client creation:

var uri = new Uri(new Uri(ConfigurationManager.AppSettings["ServicesBaseAddress"]), ConfigurationManager.AppSettings["ServiceName"]);
var channel = new ChannelFactory<ISomeService>("WCFService").CreateChannel(new EndpointAddress(uri));
var response = channel.Ping();

RESTful service invocation:

 var uri = new Uri(new Uri(ConfigurationManager.AppSettings["ServicesBaseAddress"]), ConfigurationManager.AppSettings["RESTServiceName"]);
 var response = new WebClient.DownloadString(uri);

Source files Source files

While trying to solve a problem of removing conditional execution from my code, I wanted to take advantage of .NET 4.0 and it’s dynamic capabilities. Going with DynamicObject or ExpandoObject initially didn’t get me any success since those by default support properties and indexes, but not methods. Luckily, I have a reply for my post and learned about this great OSS library called impromptu-interface. It based on DLR capabilities in .NET 4.0 and I have to admit that it made my code extremely simple – no more if :)

More Posts