My solution in Visual Studio 2012 currently contains two projects:
- DLL
- WPF application (which requires methods of the DLL)
Both, the DLL and the WPF application, use NLog
for logging. Currently each project contains the NLog
DLL itself.
Here is what I don't understand:
- It seems unnecessary to me including the identical
NLog
DLL in each project. - The DLL however shall be reusable in other solutions, i.e. somehow the
NLog
DLL must be contained in the DLL project.
What would be an adequate way of setting up the Visual Studio solution and/or projects?
well you need the DLL in all projects where you use it and surely you need it deployed with the binaries of the executable (WPF application in your case) so that it can be found and used at runtime.
what I tend to do in all my projects is create a wrapper around the logging engine so that I do not need to reference and depend on specific third party logging APIs, like Log4Net or NLog, so I use my wrapper logging class everywhere and then I have a reference to the logging asembly only in the wrapper class's project and in the executable project to have the assembly deployed to the bin folder.
hope this helps ;-)
You better abstract the use of your logging mechanism. I described this in this blog post, it's about log4net but is the same principle whatever framework you use. In any case, you need the log assembly in every project where you use it, but by abstracting it it's easy to replace it by something else (when testing for example). Logging is infrastructure, so you would put the interfaces and concrete implementation in an infrastructure project, and reference that one from the projects in which you want to log.
If your DLL is just a core library you plan on sharing among various projects, it may be wise to add an NLog reference and wrapper code to just that library, then make sure that any consumer application (such as your WPF project) has an NLog.config file associated with it.
Since you're using VS2012 I'm assuming you're also most likely working with .NET 4.5 which allows you to take advantage of the new caller info attributes. I've written the following code below for a basic NLog wrapper and believe it has the perfect balance of efficiency (doesn't use StackTrace) and usability.
Then try throwing this into the layout field of one of the targets in your NLog.config to grab the detailed caller information.