I tried to replace the ILOG object with the string as you have suggested. The next step is to tell the plugin to use the same config file as the host, because I want that the plugin is writing the logs into the same source as the host. Getting the logger and using the same config works. But when im logging something in the plugin, the plugin logger says that an other process is using the log file (cause of the different appdomains).
At the moment the config file of the logger is using the fileappender. So how i'm getting the host and the plugin writing in the same file / database / eventlogger? How is this possible? If it would possible to hand through the Ilog object from the host to the plugin this would be no problem. Greetings martin -----Ursprüngliche Nachricht----- Von: Martin Fetzel [mailto:martin.fet...@gmx.net] Gesendet: Freitag, 10. Dezember 2010 13:21 An: Log4NET User Betreff: Re: log4net serializable? thanks for the suggested solution. I'ill check this out. On Thu, 2010-12-09 at 23:10 -0600, Curt Arnold wrote: > On Dec 9, 2010, at 1:39 PM, Martin Fetzel wrote: > > > Yes it seems that i have to serialize the logger itself. The problem > > is that the new pluginmanager is using appdomains and the Ilog > > object should be serializeable. When in the Appdomain an instance of > > the plugin will be created an exception will be thrown. > > > LoggingEvent's are serializable, but serializing loggers isn't either > practical or desirable. If it were so, you'd be in essence storing the state > of the entire hierarchy of loggers, appenders and such since only if you had > the entire graph of objects would you really capture the state of a logger > and then you'd need to be able to reestablish any open files, sockets, etc to > get everything to an functionally equivalent state. > > So, it appears that you have a serializable class that has a ILog instance > member. Your solution is to replace the ILog member with a static member or > with something serializable (string for example) that can be used to > reacquire the logger after deserialization. If static isn't appropriate, the > next simplest approach would be replace the ILog with a string containing the > logger name and to call GetLogger() on demand to get a logger.
