views:

124

answers:

1

Please help I am pulling my hair out over this:

I have a Visual Studio ASP.NET MVC solution in which a project references a third party DLL, log4net in this case. My solution tree is as follows:

  • GenericLibrary
  • MyApp.NHibernate
  • MyApp.Library
  • MyApp.WebUI

MyApp.WebUI is the main start-up MVC web project and has references to GenericLibrary, MyApp.NHibernate and MyApp.Library. MyApp.NHibernate has references to all the NHibernate bits including log4net.

Now the problem is when I compile my solution the log4net dlls seem to appear and disappear from the MyApp.WebUI project's /bin directory, so NHibernate throws errors understandibly. I've had a Windows Explorer window on my second monitor looking at the web project's /bin folder, and I can see the log4net dll appear then disappearing after each compile, it seems to happen in sequence (appear, disappear, re-appearm, disappear etc.) rather than randomly.

MyApp.NHibernate project is the only project which references the log4net dll, but GenericLibrary has a reference to NHibernate but NOT log4net. MyApp.NHibernate references GenericLibrary, MyApp.Library also references GenericLibrary, but GenericLibrary stands alone.

The only solution I can think of is to add References to the main MyApp.WebUI project for every external library/dll used in my solution (Nhibernate, log4net, Castle Windsor etc.), to fix the log4net issue and avoid this happening in future. But that's not a very neat/decoupled solution to me.


Update: To answer kekekela's question, I have Copy Local set to true for both log4net reference and the MyApp.NHibernate project reference itself, see screenshot below:

alt text


Update 2: Bizzarely this problem only seems to effect log4net dll. I tried adding a different 3rd party dll to the MyApp.NHibernate project, the NLog dll, this seems to stay put whereas the log4net continues to disappear and re-appear.

+1  A: 

I was having this same issue. I changed the target framework in the project's properties dialog from ".NET Framework 4 Client Profile" to ".NET Framework 4" which seems to solve the problem. Here is an msdn article describing the differences in the target frameworks.

Christopher Bright