4

I have sort of plugin architecture in my solution. There is a well-known folder where to place plugins in it. The plugins implement an interface which is shared in the host project.

Initially i load the plugin via Assembly.LoadFrom(fi.FullName).GetTypes() and instanciate the needed type by (IPlugin)Activator.CreateInstance(type);.

So the host (main application) can execute appropriate code implemented by the plugin assembly. This works fine so far.

But recently i tried to implement application logging via NLog and configured NLog in the host project which worked great.

The problem is i would like to use (the already configured) logger in the plugin assembly. If i just reference NLog and use it by LogManager.GetCurrentClassLogger(); there seems to be no configuration set. It does not log to the files i configured in the host project out of the plugin assembly.

I thought of trying to inject an NLogger instance (created in the host project) to a property of the plugin type.

Is this possible or is there a preferred way to accomplish things like that? Thanks

dasheddot
  • 2,936
  • 4
  • 26
  • 33

2 Answers2

3

this should work - NLog configuration should work also for the loaded plugin assemblies. The problem is probably related to how your plugins are loaded. Maybe they are in a separate domain (I don't remember how it works) so NLog can't access your main applications's logging configuration.

In that case you could try adding separate nlog configuration files for your plugin assemblies (read nlog documentation about config file naming conventions).

I dont think IOC container will help you in case of dynamically loaded plugins - the container will not know about them so you will have to change the way plugins are loaded and configured. And imho using IOC for configuring nlog is not a great idea.

If the previous options don't work you could try changing the assembly probing path in app.config so your plugins are loaded into the default domain - then NLog should work for these plugins (at least works for me):

<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
  <probing privatePath="Plugins" />
</assemblyBinding>

nightwatch
  • 1,276
  • 2
  • 18
  • 27
  • Using IoC is a good idea if it has support already built in, like Ninject or Castle.Windsor's logging facilities. – Merlyn Morgan-Graham Dec 02 '11 at 10:08
  • 1
    But I assume the author already has the NLog dependency in his components (his plugins are already using NLog for logging) so externally injecting nlog is not needed. What is needed is single nlog configuration working both for application and its plugins. – nightwatch Dec 02 '11 at 10:11
  • Yes, that problem isn't one that IoC solves. I'd also expect it to *just work*, as your answer describes. The only thing I disagree with is "imho using IOC for configuring nlog is not a great idea", unless by "configuring" you mean configuring listeners/output, etc, rather than configuring the logger classes themselves. IoC is great for hooking up the logger classes. As you commented, it isn't necessary, but it can be helpful. – Merlyn Morgan-Graham Dec 02 '11 at 10:56
1

Have a look at Dependency Injection Containers like Unity or Lightcore.

They are some kind of "component registration stores"

there you can register components to interfaces. Then your consumers just need to request an interface.

The mapping of interface - component can be made in configuration files or source code.

So you can change the mapping without any pain.

For example when they are creating new instances and you are having complextypes as ctor parameters, they can make an automatic lookup if these components are registered and then inject them automatically.

Some Keywords that can help you are "ServiceLocator" "MicroKernel" "Depency Injection"

Components:

Boas Enkler
  • 12,264
  • 16
  • 69
  • 143
  • Assume i will resolve the plugin by using a DI container. The plugin itself needs a logger instance (already configured in the host system, where to log files and so on). How would this work with NLog? Can i inject the logger as already configured? – dasheddot Nov 30 '11 at 13:44
  • I'm not sure wether I understand you , but you can also register living instances to some types. For example you create a Loggerinstance and register it for ILogAdapter. Btw when using a Di container you should have a look at CommonServiceLocator, so you can change the Dic without changing your code – Boas Enkler Dec 07 '11 at 13:06