newbie usage question

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

newbie usage question

amores perros
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
Reply | Threaded
Open this post in threaded view
|

Re: newbie usage question

Jarek Kowalski
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.html

Let 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
NLog Blog
Reply | Threaded
Open this post in threaded view
|

Re: newbie usage question

amores perros



>From: Jaroslaw Kowalski <[hidden email]>
>To: amores perros <[hidden email]>
>CC: [hidden email]
>Subject: Re: [Nlog-list] newbie usage question
>Date: Mon, 17 Jul 2006 06:53:46 +0200
>
>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.html

I don't understand what you are suggesting,
because I did read that, and it prompted
my question.  I mean, you pointing me
at it suggests that I'm overlooking
something when I read it, but I'm not
sure what I'm overlooking?

As far as I could tell, it only gave instructions
for when you are using nlog with a simple
one exe case.

Unfortunately for me, perhaps, I want
to use it in a setup which is a bit more
elaborate than that.

I want to call nlog.dll from another assembly,
which is in turn a component, and is called
by multiple clients.

In the meantime, I resorted to hacking
in the config programmatically from
the client assembly, because I could
not get it to read any config file.

I cannot feasibly stuff nlog configs into
all the client exe paths, even if I knew
them ahead of time :(

It may be that my problem is that
I don't understand how .net assemblies
find dlls -- will my client assembly find
the nlog.dll that lives in the path with it,
and if so, will that nlog.dll find the nlog.config
that is in the path with it? My testing suggests
not, but I don't know where this is breaking
down.

Yet, I did not get any runtime errors, I
simply did not get any log output.

That suggests that it did find the nlog dll,
but the nlog dll failed to find the

"NLog.dll.nlog in a directory where NLog.dll is located"

At this point, I'm not sure how to
further troubleshoot.

Maybe I need some logging to record what nlog
is doing, eg,

"<nlog internalLogFile="file.txt" />-"

However, if it is not finding the config file,
I doubt that putting that in the config
file is going to help me.

I should probably be turning that
setting on programmatically somehow?



>
>Let me know if you still have problems, . In general you should put the
>NLog.config in the same directory as your EXE.
>
>Jarek

Maybe I didn't make myself very clear. My client is an
assembly, which in turn will have different exe clients.
So I don't know what clients it will have, much less where
they are.

Do you think there is a way to handle this (as I hope,
and actually think), or do you
think nlog simply cannot support this type of
component-based scenario, and I'm banging my head
against a tree, and wasting your time and mine?


My mail client set the To line to your address, and
a cc to the list, which seems odd, but I'm not sure
if it is my flaky email client, or this is how you configured
the mail headers of the list, so I'd better leave it alone
I think, and let it go this way, and apologize in advance
if I've done it wrong.

Thanks for any further suggestions or pointers (perhaps
there is another page in the documentation I should
be reading?)




-------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: newbie usage question

Jarek Kowalski
Administrator
There are 3 scenarios:

1. You control the client apps:

Put the configuration in NLog.config or appname.exe.config located in
the same directory as your exe.

2. Your service application (such as COM service) located in its own
directory which also contains NLog.dll

Put the configuration in NLog.dll.nlog in this directory.

3. You have a service application where NLog is in the GAC (NOT RECOMMENDED)

You have to use NLOG_GLOBAL_CONFIG_FILE or configure logging manually.

3.1. NLOG_GLOBAL_CONFIG_FILE - is a global, shared configuration file.
This may work if all your processes can share one logging definition.

3.2. Manual configuration (execute this code somewhere in some class
constructor):

if (LogManager.Configuration == null)
    LogManager.Configuration = new
XmlLoggingConfiguration("c:\path\to\configuration_file.nlog");

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
NLog Blog
Reply | Threaded
Open this post in threaded view
|

Re: newbie usage question

amores perros



>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.

>
>1. You control the client apps:
>
>Put the configuration in NLog.config or appname.exe.config located in the
>same directory as your exe.
>
>2. Your service application (such as COM service) located in its own
>directory which also contains NLog.dll
>
>Put the configuration in NLog.dll.nlog in this directory.
>
>3. You have a service application where NLog is in the GAC (NOT
>RECOMMENDED)
>

Just to be safe, I'll describe my scenario again quickly, which
clearly isn't one of these three (these three sound like they
are all simple one-exe scenarios).

My client is a .net assembly, which is itself a client of multiple
client exes (most of which are not services, I think).

So my client is really a component used in other systems.
The exes (end-users) have no knowledge of the use of nlog.
Only the .net assembly client (my component) knows of it.


>You have to use NLOG_GLOBAL_CONFIG_FILE or configure logging manually.
>
>3.1. NLOG_GLOBAL_CONFIG_FILE - is a global, shared configuration file. This
>may work if all your processes can share one logging definition.

To me this seems at too high a level -- it is outside of
my component, outside of these systems, and shared among
all processes run under one particular account -- or if a system
environment variable, shared among all processes run under all
accounts.

Plus it complicates deployment.


>
>3.2. Manual configuration (execute this code somewhere in some class
>constructor):
>
>if (LogManager.Configuration == null)
>    LogManager.Configuration = new
>XmlLoggingConfiguration("c:\path\to\configuration_file.nlog");
>

This 3.2 solution sounds like the best workaround for now for a
component scenario like mine. The client assembly is the only
one aware of the nlog dll, so it seems to me that the client assembly
has to be in charge of its configuration, so I think I'm happy with this.
That is, maybe I'm happy with this as the (semi-)permanent solution
-- only leaving open a door in case I think of something better, or someone
tells me something better :)

I should actually pull that path from a configuration setting in the client
assembly, I think.

Thanks for the detailed analysis.




-------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: newbie usage question

Jarek Kowalski
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
NLog Blog
Reply | Threaded
Open this post in threaded view
|

Re: newbie usage question

amores perros



>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
Reply | Threaded
Open this post in threaded view
|

Re: newbie usage question

Ron Grabowski
It sounds like you want to associate different namespaces/projects
within the same process with different/independent logging
configurations. Log4net uses a construct called a Repository to
represent the different logging partitions in an application. By
default all applications have a single Repository (similiar to a
harddrive containing only one partition). Its sounds like you want to
parition your application to use a different logging configuration for
a particular part of the logging code in your process. This would be
akin to spliting a harddrive into two partitions. Here's more
information on Repositories:

 http://logging.apache.org/log4net/release/manual/repositories.html

Is that what you want to do? If so, your application has advanced
logging requirements compared to most applications. Don't get
frustrated if things don't work the first time. Don't let my log4net
examples sway you from using NLog...I coudln't think of a real world
example of log4net's Repository design. NLog is very flexible and
should be able to handle your requirements.

--- amores perros <[hidden email]> wrote:

>
>
>
> >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
>


-------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: newbie usage question

Jarek Kowalski
Administrator
Ron Grabowski wrote:

> It sounds like you want to associate different namespaces/projects
> within the same process with different/independent logging
> configurations. Log4net uses a construct called a Repository to
> represent the different logging partitions in an application. By
> default all applications have a single Repository (similiar to a
> harddrive containing only one partition). Its sounds like you want to
> parition your application to use a different logging configuration for
> a particular part of the logging code in your process. This would be
> akin to spliting a harddrive into two partitions. Here's more
> information on Repositories:
>
>  http://logging.apache.org/log4net/release/manual/repositories.html
>
> Is that what you want to do? If so, your application has advanced
> logging requirements compared to most applications. Don't get
> frustrated if things don't work the first time. Don't let my log4net
> examples sway you from using NLog...I coudln't think of a real world
> example of log4net's Repository design. NLog is very flexible and
> should be able to handle your requirements.
>  
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:

http://svn.nlog-project.org/repos/nlog/trunk/NLog/src/NLog/LogManager.cs

This is available in the 20060718 snapshot.

http://www.nlog-project.org/snapshots/

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
NLog Blog
Reply | Threaded
Open this post in threaded view
|

Re: newbie usage question

amores perros
In reply to this post by Ron Grabowski



>From: Ron Grabowski Subject: Re: [Nlog-list] newbie usage question
>Date: Mon, 17 Jul 2006 20:43:43 -0700 (PDT)
>
>It sounds like you want to associate different namespaces/projects
>within the same process with different/independent logging
>configurations. Log4net uses a construct called a Repository to
>represent the different logging partitions in an application. By
>default all applications have a single Repository (similiar to a
>harddrive containing only one partition). Its sounds like you want to
>parition your application to use a different logging configuration for
>a particular part of the logging code in your process. This would be
>akin to spliting a harddrive into two partitions. Here's more
>information on Repositories:
>
>  http://logging.apache.org/log4net/release/manual/repositories.html
>
>Is that what you want to do? If so, your application has advanced
>logging requirements compared to most applications. Don't get
>frustrated if things don't work the first time. Don't let my log4net
>examples sway you from using NLog...I coudln't think of a real world
>example of log4net's Repository design. NLog is very flexible and
>should be able to handle your requirements.
>

I don't really think so.
I don't care about the application at all -- that is the part I keep
trying to explain. I'm working on one assembly -- ok, actually
on two assemblies, which are in turn used by various end-clients
(various applications).

This is component-based development -- I'm only focussed on
my little client assemblies, and I want to make them log.
(Ok, I had them logging before, but I want to make them
log with nlog to get fancier runtime configuration).

I think the big difference is that I am not doing monolithic
application development -- one big client with all the entire
app code in one big chunk.

I'm doing one little assembly and want it to log.

And I'm also doing another little assembly and want it to log
separately.

But it so happens that at least one client uses both these
assemblies so they wind up both running in the same
process space.

I don't really feel that this is very advanced -- it just
isn't very monolithic :)



-------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: newbie usage question

amores perros
In reply to this post by Jarek Kowalski



>From: Jaroslaw Kowalski <[hidden email]>
>To: Ron Grabowski <[hidden email]>
>CC: [hidden email]
>Subject: Re: [Nlog-list] newbie usage question
>Date: Tue, 18 Jul 2006 09:10:23 +0200
>MIME-Version: 1.0
>Received: from lists-outbound.sourceforge.net ([66.35.250.225]) by
>bay0-mc1-f11.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2444); Tue,
>18 Jul 2006 00:10:22 -0700
>Received: from sc8-sf-list2-new.sourceforge.net (unknown [10.3.1.94])by
>sc8-sf-spam2.sourceforge.net (Postfix) with ESMTPid 4DDCFF5F6; Tue, 18 Jul
>2006 00:10:21 -0700 (PDT)
>Received: from sc8-sf-mx2-b.sourceforge.net
>([10.3.1.92]helo=mail.sourceforge.net)by sc8-sf-list2-new.sourceforge.net
>with esmtp (Exim 4.43)id 1G2jil-0005lV-2Yfor
>[hidden email]; Tue, 18 Jul 2006 00:10:19 -0700
>Received: from host-20.noc.atman.pl ([217.149.245.20] helo=sav.net)by
>mail.sourceforge.net with esmtps (TLSv1:AES256-SHA:256)(Exim 4.44) id
>1G2jii-0002qU-SLfor [hidden email]; Tue, 18 Jul 2006
>00:10:19 -0700
>Received: from jaak.homedns.org ([10.56.0.2])by sav.net (8.13.6/8.13.4)
>with ESMTP id k6I7AAcH012930;Tue, 18 Jul 2006 09:10:10 +0200
>Received: from [10.25.0.2] ([10.25.0.2])by jaak.homedns.org (8.13.6/8.13.6)
>with ESMTP id k6I7Adal014530;Tue, 18 Jul 2006 09:10:39 +0200
>X-Message-Info: LsUYwwHHNt2e9tfe6S9C80/AQIUS1w264UFMlzXvcuE=
>User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
>References: <[hidden email]>
>X-Spam-Score: 1.0 (+)
>X-Spam-Report: Spam Filtering performed by sourceforge.net.See
>http://spamassassin.org/tag/ for more details.Report problems
>tohttp://sf.net/tracker/?func=add&group_id=1&atid=2000011.0
>FORGED_RCVD_HELO       Received: contains a forged HELO
>X-BeenThere: [hidden email]
>X-Mailman-Version: 2.1.8
>Precedence: list
>List-Id: <nlog-list.lists.sourceforge.net>
>List-Unsubscribe:
><https://lists.sourceforge.net/lists/listinfo/nlog-list>,<mailto:[hidden email]?subject=unsubscribe>
>List-Archive:
><http://sourceforge.net/mailarchive/forum.php?forum=nlog-list>
>List-Post: <mailto:[hidden email]>
>List-Help: <mailto:[hidden email]?subject=help>
>List-Subscribe:
><https://lists.sourceforge.net/lists/listinfo/nlog-list>,<mailto:[hidden email]?subject=subscribe>
>Errors-To: [hidden email]
>Return-Path: [hidden email]
>X-OriginalArrivalTime: 18 Jul 2006 07:10:23.0255 (UTC)
>FILETIME=[3C8FC270:01C6AA39]
>
>Ron Grabowski wrote:
> > It sounds like you want to associate different namespaces/projects
> > within the same process with different/independent logging
> > configurations. Log4net uses a construct called a Repository to
> > represent the different logging partitions in an application. By
> > default all applications have a single Repository (similiar to a
> > harddrive containing only one partition). Its sounds like you want to
> > parition your application to use a different logging configuration for
> > a particular part of the logging code in your process. This would be
> > akin to spliting a harddrive into two partitions. Here's more
> > information on Repositories:
> >
> >  http://logging.apache.org/log4net/release/manual/repositories.html
> >
> > Is that what you want to do? If so, your application has advanced
> > logging requirements compared to most applications. Don't get
> > frustrated if things don't work the first time. Don't let my log4net
> > examples sway you from using NLog...I coudln't think of a real world
> > example of log4net's Repository design. NLog is very flexible and
> > should be able to handle your requirements.
> >
>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:
>
>http://svn.nlog-project.org/repos/nlog/trunk/NLog/src/NLog/LogManager.cs
>
>This is available in the 20060718 snapshot.
>
>http://www.nlog-project.org/snapshots/
>
>Jarek
>
>

This sounds like exactly what I want; thank you!


To test my understanding, and to try to help
a tiny bit, I modified your write-up slightly to
try to make it a bit more FAQ-like:

---------------------------------


* How do I configure NLogging for a component?


If you can configure NLogging on the client-side, you can
follow the tutorial (which is oriented towards logging from
an application).

However, if you do not control the clients, or they are
not all local, or you wish a solution encapsulated to your
component or assembly, you may wish to configure NLogging
locally in your component assembly.

Create a log manager just for your component.

The following solution is usable for components not in the GAC.

(Components in the GAC need to implement
below method GetNLogConfigFilepath in some
application-dependent fashion.)

internal class MyLogManager
  {
    // A Logger dispenser for the current assembly
    public static read only LogFactory Instance
            = new LogFactory(
                new XmlLoggingConfiguration(GetNLogConfigFilepath));

    // Use a config file located next to our current assembly dll
    // eg, if the running assembly is c:\path\to\MyComponent.dll
    // the config filepath will be c:\path\to\MyComponent.dll.config
    // WARNING: This will not be appropriate for assemblies in the GAC
    private string GetNLogConfigFilepath()
    {
       // Use name of current assembly to construct NLog config filename
       System.Reflection.Assembly thisAssembly
         = System.Reflection.Assembly.GetExecutingAssembly();
       string assempath = Path.GetDirectoryName(thisAssembly.CodeBase);
       string configfile = thisAssembly.GetName().Name + ".NLog.config";
       return assempath + "\\" + configfile;
    }
  }

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. That is,
this will not interfere with other assemblies or the application
exe itself using NLog.


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:

http://svn.nlog-project.org/repos/nlog/trunk/NLog/src/NLog/LogManager.cs

This is available in the 20060718 snapshot.

http://www.nlog-project.org/snapshots/



-------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: newbie usage question

Jarek Kowalski
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.net
http://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
NLog Blog
Reply | Threaded
Open this post in threaded view
|

Re: newbie usage question

amores perros
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
Reply | Threaded
Open this post in threaded view
|

Re: newbie usage question

amores perros
In reply to this post by Jarek Kowalski
>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.



-------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: newbie usage question

gk-2
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?
Reply | Threaded
Open this post in threaded view
|

Re: newbie usage question

Jarek Kowalski
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
NLog Blog
Reply | Threaded
Open this post in threaded view
|

Re: newbie usage question

amores perros
>
>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

That sounds good -- combining that with moving the loggers
into instance-based and being created inside the constructor
should help move towards where I at least have a chance
at trapping exceptions. I will try to fight the good fight
a little bit longer.

Earlier you warned that messages may be lost unless
shutdown is also trapped, and pointed me at one of
your source files. I followed its model, like so:



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;
                        SetupTerminationEvents();
                        _instance.Configuration = config;
                    }
                    return _instance;
                }
            }
        }

        private static void SetupTerminationEvents()
        {
            AppDomain.CurrentDomain.ProcessExit += new
EventHandler(TurnOffLogging);
            AppDomain.CurrentDomain.DomainUnload += new
EventHandler(TurnOffLogging);
        }
        private static void TurnOffLogging(object sender, EventArgs args)
        {
            lock (typeof(MyLogManager))
            {
                if (_instance != null)
                {
                    Instance.Configuration = null;
                }
            }
        }

        private static string GetNLogConfigFilePath()
        {
            // Use name of current assembly to construct NLog config
filename

            Assembly thisAssembly = Assembly.GetExecutingAssembly();

            return Path.ChangeExtension(thisAssembly.Location, ".nlog");
        }
    }



-------------------------------------------------------------------------
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