# newbie usage question

17 messages
Open this post in threaded view
|

## newbie usage question

 Newbie questions about where to put nlog.dll and config when called from another assembly... I'd like to use NLog.dll from another .net component (assembly). Where do I put the config file? My client .net assembly dll is in the GAC, from a particular path on the client machine. Let's say I have clientexe1.exe   in exepath1 clientexe2.exe in exepath2 clientassembly.dll   in assemblypath nlog.dll nlog.config Can I put nlog.dll in the directory (assemblypath) with clientassembly.dll? Can I put nlog.config in there also? Thanks for any suggestions. ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642_______________________________________________ Nlog-list mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/nlog-list
Open this post in threaded view
|

## Re: newbie usage question

 Administrator amores perros wrote: > Newbie questions about where to put nlog.dll and config > when called from another assembly... > > > I'd like to use NLog.dll from another .net component (assembly). > > Where do I put the config file? > > > My client .net assembly dll is in the GAC, from a particular path on > the client machine. > > Let's say I have > > > clientexe1.exe >   in exepath1 > > clientexe2.exe > in exepath2 > > clientassembly.dll >   in assemblypath > > nlog.dll > nlog.config > > > Can I put nlog.dll in the directory (assemblypath) with clientassembly.dll? > Can I put nlog.config in there also? >   Please read http://www.nlog-project.org/config.htmlLet me know if you still have problems, . In general you should put the NLog.config in the same directory as your EXE. Jarek ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642_______________________________________________ Nlog-list mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/nlog-list
Open this post in threaded view
|

## Re: newbie usage question

Open this post in threaded view
|

## Re: newbie usage question

Open this post in threaded view
|

## Re: newbie usage question

Open this post in threaded view
|

## Re: newbie usage question

 Administrator amores perros wrote: > >   >> From: Jaroslaw Kowalski >> Subject: Re: [Nlog-list] newbie usage question >> Date: Mon, 17 Jul 2006 15:34:05 +0200 >> >> There are 3 scenarios: >>     > > As you didn't include my scenario, that is bad news for me I guess. >   Is your component stored in the GAC? If it isn't, things should work. Can you use filemon.exe from sysinternals.com to verify the list of files NLog is trying to open? Jarek ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642_______________________________________________ Nlog-list mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/nlog-list
Open this post in threaded view
|

## Re: newbie usage question

 >From: Jaroslaw Kowalski >CC: [hidden email] >Subject: Re: [Nlog-list] newbie usage question >Date: Mon, 17 Jul 2006 18:15:40 +0200 > >amores perros wrote: >> >> >>>From: Jaroslaw Kowalski >>>Subject: Re: [Nlog-list] newbie usage question >>>Date: Mon, 17 Jul 2006 15:34:05 +0200 >>> >>>There are 3 scenarios: >>> >> >>As you didn't include my scenario, that is bad news for me I guess. >> > >Is your component stored in the GAC? My client assembly is stored in the GAC, yes. I thought I mentioned that; anyway I meant to do so. I have it kind of working now. There was a bug in the code you posted earlier, which I found because I oversimplified what I am doing. Actually I have multiple client uses in different dlls but they may wind up loaded in the same process space. I think that NLog configuration is shared across all clients in the same process, so you have to be careful of your assumptions. Anyway, the fix is this:         NLog.LogManager.Configuration cfg = new NLog.Config.XmlLoggingConfiguration(nlogCfgPath); (Do not first check if there is a configuration, because there may be a configuration already present due to some other client in the same process, but that is not our configuration. The earlier code incorrectly left active the configuration from some other assembly.) I get the current assembly name, and then an NLog path from somewhere in the registry, and then specify an NLog config file by combining those two, eg, string nlogCfgPath = "z:\path\to\my_components_nlogging\myAssembly.NLog.config"; Now, I'm not sure this will work -- I'm getting messages, but I've not set up enough and paid enough attention to check if NLog is correctly handling having multiple client assemblies with different NLog configurations being called in the same process space. Am I going to get burned because NLog is going to confuse these instances, because they're in the same process space? >If it isn't, things should work. Can you use filemon.exe from >sysinternals.com to verify the list of files NLog is trying to open? I could, but (a) filemon is tedious to use because it produces so much output, and (b) I'm not sure what to test with this now, because this programmatically setting the config full path seems to be working (unless I run into a problem with contention between different clients in the same process space). If NLog cannot handle different clients in the same process each with their own configuration, I think I can work around it by redesigning them to all use the same configuration file -- so that if they are contending, they are all contending towards the same answer -- but it would be less optimal I think. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________ Nlog-list mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/nlog-list
Open this post in threaded view
|

## Re: newbie usage question

Open this post in threaded view
|

## Re: newbie usage question

Open this post in threaded view
|

## Re: newbie usage question

Open this post in threaded view
|

## Re: newbie usage question

Open this post in threaded view
|

## Re: newbie usage question

 Administrator Tanks. I've updated the faq on the web. Would you like me to add you to the AUTHORS.txt ? http://svn.nlog-project.org/repos/nlog/trunk/NLog/AUTHORS.txt-- Jarek Kowalski http://blog.jkowalski.nethttp://www.nlog-project.org/ - A .NET Logging Library ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________ Nlog-list mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/nlog-list
Open this post in threaded view
|

## Re: newbie usage question

 In reply to this post by Jarek Kowalski >From: Jaroslaw Kowalski <[hidden email]> ... >This is available in the 20060718 snapshot. > >http://www.nlog-project.org/snapshots/> In which I just tested NLog.vs2003.sln with Visual Studio 2003, and the only error I see building is the (probably expected): ------ Build started: Project: NLog.ComInterop.vs2003, Configuration: Debug .NET ------ Preparing resources... Updating references... Performing main compilation... Build complete -- 0 errors, 0 warnings Building satellite assemblies... Registering project output for COM Interop... COM Interop registration failed. Access to the registry key HKEY_CLASSES_ROOT\NLog.Logger is denied. and I just tested NLog.vs2005.sln compiling in Visual Studio 2005 and I see no errors and only one warning: src\NLog.ComInterop\AssemblySign.cs(39,12): warning CS1699: Use command line option '/keyfile' or appropriate project settings instead of 'AssemblyKeyFile' So apparently all the files are referenced successfully in this snapshot, in both 2003 & 2005 solutions. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________ Nlog-list mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/nlog-list
Open this post in threaded view
|

## Re: newbie usage question

Open this post in threaded view
|

## Re: newbie usage question

 In reply to this post by Jarek Kowalski I have had exactly the same problem. 2 dlls that need logging for themselves that live on foreign EXE. Looking at the code I believe there is nothing wrong with what was suggested on the reply of: amores perros 2006-07-17 19:30 Every time you load a config it stays inside the manager. It does not get overwritten. I have managed successfully to have seperate logging for the 2 dlls. Will this not work properly?
 Administrator In reply to this post by amores perros amores perros wrote: From: Jaroslaw Kowalski Subject: Re: [Nlog-list] newbie usage question Date: Tue, 18 Jul 2006 09:10:23 +0200   ....  How about allowing multiple instances of LogManager? Each would have its own configuration, loggers and so on. You'd have to create it manually but then you'd get a fully partitioned NLog configuration. I've just committed a class called "LogFactory" which is essentially a LogManager, but with all fields/properties turned into instance. LogManager was converted to use this new class internally while preserving its public static interface. Once we have this log factory class, you can build your own, private LogManager which holds a single instance of LogFactory (similar to singleton) very easily: internal class MyLogManager { public static read only LogFactory Instance = new LogFactory(new XmlLoggingConfiguration("c:\\path\\to\\NLog.config")); } Then create loggers with: Logger logger = MyLogManager.Instance.GetLogger("name"); or Logger logger = MyLogManager.Instance.GetCurrentClassLogger(); The loggers are independent from the ones created with NLog LogManager and thus you can have safe private logging. If you want multiple assemblies to share this MyLogManager - just make it a public class and get others to use it. You need to make sure that the configuration is properly closed when the process terminates (set MyLogManager.Instance.Configuration to null) or you may lose some log output. You may want to hook AppDomain.ProcessExit and AppDomain.DomainUnload events to turn off logging automatically. See the code:   I tried for a while to get this to work, but I'm tired of fighting type exceptions -- and it is too difficult to debug when it is the logging framework that doesn't work. I think all the static stuff is a mistake probably -- I think I'd like to get away from static objects, as they may be giving opportunities for threading problems. Is there a way to do the following, really simple use model? class MyComponent { NLog.Logger myLogger = null; public MyComponent() { string logconfig = GetNLogConfigFilepath(); // does magic try { // Help? How to do? // I know this should be easy // but I am just confused by the configuration and manager objects myLogger = CreateNewLoggerFromConfigFile(logconfig); } catch(Exception exc) { ReallyLogText("Failed to create NLog logger: " + exc.Message); } } ~MyComponent() { myLogger.Close(); } } That is, I'd just like to create a logger for my instance, use it while my object is alive, and then free it when my object dies -- no static anything. This way if there is an exception thrown by the NLog code, at least it will be during the lifetime of my instance, not during some static construction pre-instance time. I can always later work back towards the efficiency optimizations of static objects and managers, but I need to start with a simple setup where log messages actually appear, because I'm so terribly unfamiliar with this object model.  1. LogManagers are necessary to implement dynamic reconfiguration and file watching. I'm afraid there's nothing that can be done about. 2. You can of course make your logger not static. Everything should work just fine. 3. I suggest that you tried the following version of MyLogManager which implements lazy creation, so that you don't get any class initialization exceptions but some useful stack traces instead.     internal class MyLogManager     {         private static LogFactory _instance;         static MyLogManager()         {         }         public static LogFactory Instance         {             get             {                 lock (typeof(MyLogManager))                 {                     if (_instance == null)                     {                         _instance = new LogFactory();                         XmlLoggingConfiguration config = new XmlLoggingConfiguration(GetNLogConfigFilePath());                         config.AutoReload = true;                         _instance.Configuration = config;                     }                     return _instance;                 }             }         }         private static string GetNLogConfigFilePath()         {             // Use name of current assembly to construct NLog config filename             Assembly thisAssembly = Assembly.GetExecutingAssembly();             return Path.ChangeExtension(thisAssembly.Location, ".nlog");         }     } Jarek ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________ Nlog-list mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/nlog-list