Cook! Where's my dll?

by coatta 5/4/2011 8:58:00 AM

I've been working on a little sample project in DevStudio to check out NuGet. Writing the code, using NuGet, and getting things to build all went fine. But when I went to run the code, it failed. Because I had set the project up as a Windows service, debugging was not entirely straightforward -- all I had were some stack traces in the event log. The service had died because of an an exception: Castle.MicroKernel.SubSystems.Conversion.ConverterException. The stack trace indicated that the exception was occurring during the process of getting logging initialized. After a bit more poking around I realized that there was a DLL missing from the bin folder of the project: Castle.Services.Logging.Log4netIntegration.dll.

So, back to the project to make sure that I've got the reference added for that. Yup, there's the reference. OK, check the Copy Local setting. Yup, set to true. OK, check the universal mind (aka Google) to see what it recommends. Hmmm. MSDN docs say that if the assembly is in the GAC, then DevStudio won't copy the dll to the output directory. OK, check GAC. Nope, that assembly is not in the GAC. At this point I resort to one of my favourite tools: stumbling around blindly.

To make a long (and painful) story short, I eventually discovered that I had the Target Fraemwork for the project set to .NET 4 Framework Client Profile. I'm not sure how I managed that, because its a setting I would never normally use. However, here's what was happening as best I can tell: The log4net integration assembly has dependencies on assemblies that are part of the .NET 4 Framework, but are not in the Client Profile. While DevStudio was happy to let me add a reference to the integration assembly to the project, when it came time to do the build, it apparently regretted allowing me to make that mistake and decided that it should not copy the integration dll to the output directory. Because, of course, it wouldn't work since its dependencies would not be satisfied.

Sadly, DevStudio failed to inform me of any of its internal considerations of the issue resulting several hours of suffering (for me, not DevStudio... how I wish I could inflict pain on DevStudio).

Lesson: If an assembly fails to copy to the output directory, check your target framework and makes sure its consistent with all your references.
 

Related posts

Comments


Calendar

<<  June 2017  >>
MoTuWeThFrSaSu
2930311234
567891011
12131415161718
19202122232425
262728293012
3456789

View posts in large calendar

Disclaimer

My opinions are my own, but you can borrow them if you like.

© Copyright 2017

Sign in