S h o r t S t o r i e s

// Tales from software development

Archive for August 2011

NUnit and application configuration files (again)

leave a comment »

I suggested in NUnit and application configuration files that the config file for the application being tested under NUnit could be copied in the test setup method from where it was known to be to the location that the AppDomain that NUnit had created indicated it expected to find it, as specified in the AppDomain.CurrentDomain.SetupInformation.ConfigurationFile property.

This works OK when the application is using the .NET Settings support that was introduced in .NET 2.0. These settings are found under the applicationSettings element in the config file.

However, I’ve now found that if the application uses the System.Configuration.Configuration manager directly then copying the config file doesn’t seem to provide a usable solution because it seems that this gets initialised very early in the process of setting up the execution environment, i.e. before the test setup method copies the config file to the location specified by AppDomain.CurrentDomain.SetupInformation.ConfigurationFile.

In this case the only thing that works is to follow the information regarding config files in the NUnit documentation. If you’re using one AppDomain for all your test assemblies then you need to create a copy of the config file with the same filename as the NUnit project but with a file extension of .config.

Written by Sea Monkey

August 18, 2011 at 8:00 pm

Posted in Development

Tagged with ,

Assembly Location and CodeBase

with one comment

I’ve just found out the hard way why I should have been using Assembly.CodeBase rather than Assembly.Location.

When I need to find a file or assembly that’s in the same folder as the assembly that’s executing I generally use Assembly.GetExecutingAssembly().Location, e.g.

string logPath = Path.Combine(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location), "application.log");


Most of the time this works fine but it’s relying on the false assumption that the location the currently executing assembly was loaded from is the same location where your other files and assemblies are. There are some scenarios where this isn’t the case. For example, depending on how it’s configured, NUnit may copy the assembly being tested to a temporary folder but set its CodeBase to the original folder so that referenced assemblies are successfully located. As an example of this, while debugging an NUnit test a couple of days ago I found that the assembly being tested had a CodeBase of

file:///C:/svn/HL7/trunk/Solutions/HL7/Tests/bin/Release/Vitality.HL7.Processor.Tests.EXE


but its Location was

C:\Documents and Settings\SeaMonkey\Local Settings\Temp\nunit20\ShadowCopyCache\5312_634473125209531250\Tests\assembly\dl3\2aaca1d6\6a30ec8c_d24bcc01\Vitality.HL7.Processor.Tests.EXE


In this scenario, using Location to locate a file that I knew was in the same folder as the assembly fails because NUnit has copied the assembly somewhere else before executing it. However, the CodeBase property provides the information I need. The only problem is that it’s a URI rather than a file system path but creating a Uri instance and referencing its LocalPath property provides a simple means to convert the URI to a file system path:

Uri codeBase = new Uri(Assembly.GetExecutingAssembly().CodeBase);
string logPath = Path.Combine(Path.GetDirectoryName(codeBase.LocalPath), "application.log");


Written by Sea Monkey

August 3, 2011 at 8:00 pm

Posted in Development

Tagged with ,

Embedded spaces in SVN paths

leave a comment »

Useful tip: You can specify the %20 literal for a space in SVN protocol urls as well as HTTP protocol urls.

Written by Sea Monkey

August 1, 2011 at 8:00 pm

Posted in Subversion

Tagged with