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

// Tales from software development

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


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 ,

One Response

Subscribe to comments with RSS.

  1. Works a treat to fix Appveyor ShadowCopyCache problem. Thanks.


    November 12, 2015 at 5:22 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: