Take the 2-minute tour ×

I am getting the following error:

Microsoft Visual Studio
Could not load the assembly Common.Logging.NLog because the following errors occurred:

Could not load type 'NLog.TargetWithLayout' from assembly 'NLog, Version=, Culture=neutral, PublicKeyToken=5120e14c03d0593c'.

When I try to use the DataContext editor / selector any the Window/Usercontrol properties. I pulled both assemblies down from NuGet

NLog Config:


  See http://nlog-project.org/wiki/Configuration_file 
  for information on customizing logging rules and outputs.
    <variable name="appName" value="APPLICATION" />
    <targets async="true">
        <target xsi:type="File"
                layout="${longdate} | ${uppercase:${level}} | ${message}${onexception:${newline}EXCEPTION\: ${exception:format=ToString}}"
                keepFileOpen="false"  />
        <target xsi:type="File"
                keepFileOpen="false"  />
        <target xsi:type="EventLog"
                layout="${message}${newline}${exception:format=ToString}" />

        <logger name="*" writeTo="debug" minlevel="Trace" maxlevel="Debug" />
share|improve this question
Can you show us your NLog.config file? –  sonofaforester Dec 4 '12 at 3:16
@sonofaforester added –  John Dec 4 '12 at 19:57
Anyone know what could be causing this issue? –  John Dec 11 '12 at 20:16
add comment

1 Answer

up vote 1 down vote accepted

I had the same problem and I fixed it by referencing Common.Logging inside the module which had the view/designer problem. It looks like something I was referencing in my namespace definitions had a dependency on Common.Logging being findable for that project. i.e. my module depended on another custom class library that used common.

Strange way for this problem to manifest, and useless error from the designer, but adding the refence fixed it.

share|improve this answer
It will be a while until I can work on that project again (it ran fine just VS error) to verify but I'll assume you are correct in what was causing the issue. Thank you very much! :) –  John Feb 8 '13 at 21:07
Sorry to say I'm not entirely right, it seemed to help at first but then the problem came back. We have a strong suspicion that it is related to a static initialiser in a class being instantiated by the desgner, and thus the major suspect is LogManager.GetCurrentClassLogger() as this looks to be doing some nasty reflection. The problem is now on the back burner for us though as moving to VS2012 the designer is a lot more robust so it no longer blows up. It also has some more meaningful errors so I will drill in further as time allows. In the meantime we are using GetLogger() instead. –  DanH Feb 11 '13 at 12:51
add comment

Your Answer


