Changing a DLL Project to EXE

NUnit supports having a '.config' file associated with a test assembly.  When creating a new app domain, NUnit looks for a file with the same file name as the test assembly but ending with '.config' (eg My.Tests.dll.config).  This is similar to the way .NET uses EXE.config files when a new process is started.

The only problem here is that your DLL probably ends up in a 'bin\Debug' or 'bin\Release' directory.  You could just copy the '.config' files there, but do you really want to be checking files in these directories into version control?  One possible solution is to put your tests in an EXE project. Doing it this way means Visual Studio will copy any 'app.config' file into the correct place. As Kiwidude pointed out you can even create a link to the 'app.config' file in your real project. Now that is pretty neat.  There is one subtle gotcha that it far too easy to fall into...

Kiwidude said:

My excitement at this new solution was sadly short-lived... for whatever reason the 'Test With Debugger' functionality does not appear to work when the test project type is an executable. Breakpoints in the test case code itself are ignored - although breakpoints are caught in the .dlls that the test code calls. Looking at the call stack it appears the test cases are on the 'wrong side' of the remoting boundary when contained in an executable... switching the project type back to a .dll and the test case breakpoints magically work again. Excuse my ignorance but I assume there is some logical reason for this rather than it being a bug?

When you change a DLL project to an EXE project, Viausl Studio will leave a copy of the old DLL in the output directory. This can cause all kinds of maddening and subtle bugs. The problem is the EXE will end up in the LoadFrom binding context whereas the DLL will end up in the Load binding context. After being burnt numerous times I have taken to always using Assembly.Load rather than Assembly.LoadFrom if at all possible. Unfortunately in this case it will mean the original DLL will be loaded instead of the EXE. I suspect this is what is causing the 'Test With Debugger' issue. With any luck deleteing the old DLL will fix it.

[Update] Darrell made me realise I completely missed out any kind of introduction. :o)
[Update] See comments for Kiwidude's explanation of why doing it this way is a good idea.

3 Comments

  • If you are using NUnit, it automatically loads a config file for dlls as long as the dll is named myAssembly.dll.config. Of course, as master of the NUnitAddin (and various other Managed Addins), you already knew that. :)

  • Mate, you are a legend... deleting the original .dll worked like a charm... Also explains why some extra debug code I threw in my tests wasn't working since unknown to me the add-in was not even loading it... doh!



    To answer your point Darrell - the whole point I was trying to achieve is sharing a single app.config file across multiple test projects. You are 100% right about your approach in naming the config file that way - the problem is the maintenance involved if you have lots of test projects all requiring the same .config file contents... Some sort of post-build task would be the other option that I never investigated (plus another step to go wrong), but this linked app.config/output executable approach will do me just fine...

  • Setting up post build event is not that hard. All you need is:



    copy $(ProjectDir)$(TargetFileName).config $(TargetDir)



    I never had problems with it once it was set up. Actually I usually have filename instead of macro, but that was because I was too lazy to make that final touch.

Comments have been disabled for this content.