Category Archives: .NET

.NET Installer cannot access your App.config

I’ve been caught by this once before and so it’s time to ensure it’s documented.

I’ve created an Installer for a Windows Service in .NET, it’s a fairly generic service (or more succinctly it’s an application that allows me to create services with minimal code) so I want it to be easy to give it a service name that properly represents it’s functionality (not the generic container’s name). So I added an appSettings section to the App.config and tried to install the service using InstallUtil and ofcourse it failed to get the info. from the App.Config.

Whilst the code for the Installer is within the EXE assembly, it’s run via InstallUtil so cannot pick up the correct App.config automatically. It’s simple to implement this functionality, see the code below

string configFile = Assembly.GetExecutingAssembly().Location + ".config";

ExeConfigurationFileMap map = new ExeConfigurationFileMap();
map.ExeConfigFilename = configFile;

Configuration config = ConfigurationManager.OpenMappedExeConfiguration(map,   
                              ConfigurationUserLevel.None);
	
string serviceName = config.AppSettings.Settings["ServiceName"].Value;
serviceInstaller.ServiceName = serviceName ?? DEFAULT_SERVICE_NAME;

In the sample above I have a fallback DEFAULT_SERVICE_NAME in case we forget to set the config as follows

<appSettings>
  <add key="ServiceName" value="My Application"/>
</appSettings>

Beware of using RegexOptions.Compiled Regex in some situations

Using the RegexOptions.Compiled option in a Regex instance means that the regular expression is compiled into IL upon creation, which sounds good.

But beware, it can be an expensive operation which highlights itself if the code is called many times. If the Regex instance is reused a lot it makes sense to use this option, but even then beware that the time to create the compiled expression might not be worth it in a one-off scenario. In such cases do not use RegexOptions.Compiled.

Let’s look at some results of a simple test.

In the first example I’m simple creating the Regex in a method and calling the Split method on it, so these results obviously include the creation and use of the object. “Option” denotes whether the Regex was compiled or interpreted and the number column denotes is the number iterations calling we make creating a Regex and using it (time is shown in ms)

[table “” not found /]

Next we’ll create the Regex and reuse it

[table “” not found /]

Obviously what you see in the second table is that when the Regex Split is called a low number of times the performance gain of compiling the expression is minimal, but it gets progressively better the more times the regex is used.

So the lesson is to not use the RegexOptions.Compiled option unless you’re pretty sure the performance hit of creating the Regex isn’t an issue and it will be called a large number of times. All other times do not used RegexOptions.Compiled.

Note: performance tests were carried out on a 32-bit Windows XP machine

Mixed mode assemblies exception

Occasionally I get caught out by an assembly in .NET having been compiled in, say, .NET 2.0 and now wanting to use it in a newer version of .NET, for example .NET 4.0.

You’ll probably see an error like the following

System.IO.FileLoadException: Mixed mode assembly is built against version ‘v2.0.50727’ of the runtime and cannot be loaded in the 4.0

Obviously if I could recompile the offending 2.0 assembly I would, but this occasionally happens with libraries such as those imported into an application via NuGet and I really don’t need the headache of finding the original source and rebuilding.

So to fix this simple add the following to the App.Config in the configurations section

<startup useLegacyV2RuntimeActivationPolicy="true">
   <supportedRuntime version="v4.0"/>
</startup>