If you have several applications that are using NLog, it can be a good idea to install NLog into the GAC and reference that.
A gotcha you must watch out for is caused by this piece of configuration from the NLog site:
<configuration>
<configSections>
<section name="nlog" type="NLog.Config.ConfigSectionHandler, NLog"/>
</configSections>
<nlog>
</nlog>
</configuration>
Because you are not using the strong name for the Assembly-qualified name of ConfigSectionHandler, it’s impossible to do a GAC lookup, therefore NLog won’t be found and you’ll get an application error (even if NLog is actually in the GAC).
This means your application will throw an exception when the configuration is loaded; there will be no NLog.dll in your application folder and it can’t check the GAC as it doesn’t have the strong name of the assembly you want.
You can fix this by including the strong name:
<section name="nlog" type="NLog.Config.ConfigSectionHandler, NLog, Version=1.0.0.505, Culture=neutral, PublicKeyToken=5120e14c03d0593c" />
That looks like good info about NLog and the GAC. Have you used NLog deployed in the GAC? I am on a project where we are working on a “common” logging component for use by developers in our organization. In essence, we are using Common.Logging as a logging abstraction and NLog as the actual framework (this is an attempt (misguided?) to “future proof” our code by not being dependent on a specific logging framework). Anyway, our development standards pretty much mandate that “common” components used across our applications be deployed (for development boxes as well as when installed at customer sites) via the GAC.
I guess I was wondering if you had any opinions one way or the other (or any experiences to share) regarding using NLog from the GAC.
Thanks!