Nabble - NLog-list

Re: NLog and ASP.NET / Medium Trust

2008-11-16T14:07:21Z

On this topic.... I have a production server that behaves differently to the corresponding test and dev boxes?

${callsite} is returning "NLog.LoggerImpl.Write"

I was thinking this might be a reflection/trust issue? anyone know of anything else that might cause this behavior?

same code works fine on my test and dev machines?

Cheers,

Stonie.

2008/11/15 Jaroslaw Kowalski <jaak@...>

It's on my todo list for V2. I'm not sure to what extent this is possible, given how reflection-intensive NLog is but I'll give it a try.

Jarek

----- Original Message -----

From: glenn_lanier@...

To: nlog-list@...

Sent: Friday, November 14, 2008 11:00 AM

Subject: [Nlog-list] NLog and ASP.NET / Medium Trust

Is there any way to run NLog in a medium trust environment (ASP.NET)?

--G

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________
Nlog-list mailing list
Nlog-list@...
https://lists.sourceforge.net/lists/listinfo/nlog-list

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Nlog-list mailing list
Nlog-list@...
https://lists.sourceforge.net/lists/listinfo/nlog-list

--
Kind regards,
----------------------------------------
Andrew Stone
Microsoft .NET Consultant

AndrewStone.net
mailbox@...
http://andrewstone.net
+61 (0)412 488 251
----------------------------------------

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Nlog-list mailing list
Nlog-list@...
https://lists.sourceforge.net/lists/listinfo/nlog-list

Re: New feature coming to NLog v2 - wrapper layout renderers

2008-11-16T13:46:11Z

Jarek,

If it's about making the code base more testable and maintainable sounds like a great idea.

You have done such a great job of 1.x! It's easy to use and has great performance.

Keep up the great work, NLog really is the best logging block for .NET.

Cheers,

Stonie.

2008/11/15 Jaroslaw Kowalski <jaak@...>

With the code cleanup that's happening in NLog v2 branch I realized that I could easily add a cool feature: Wrapper Layout Renderers which would help me restructure code to make it more maintainable and testable. I'd like to year your opinion about it.

What are Wrapper Layout Renderers (WLRs)?

Similar to wrapper targets, WLRs can modify output of other layout renderers, by doing textual transformations like:

* uppercase/lowercase conversion

* padding, trimming, alignment

* search/replace

* elision of excessive text

* encryption / masking of sensitive information

* cryptographic transformations (calculating MD5, SHA1 hashes, HMAC checksums)

* encoding: base64/uuencode, etc.

etc.

Note that many of those concerns are currently (in NLog v1) handled by LayoutRenderer itself. Being able to separate them into standalone, extensible classes is very convenient as you can add them separately and all existing layout renderers will be able to benefit from them.

So how are they used:

${uppercase:${level}} - will print log level in uppercase

${rot13:${message}} - will print ROT13 "encrypted" message

For config-file-level compatibility, you will still be able to use uppercase,lowercase,padding attributes that you know from NLog v1 directly on layout renderers etc.

To implement a wrapper, all you have to do is to create a class derived from WrapperLayoutRendererBase that overrides the Transform() method and apply the usual LayoutRenderer attribute.

Here's the ROT13 wrapper, which implements Caesar's cipher.

[
LayoutRenderer("rot13")]
public sealed class Rot13LayoutRendererWrapper: WrapperLayoutRendererBase
{
    protected override string Transform(string text)
    {
        return DecodeRot13(text);
    }
}
You can of course define public properties as be able to set their values as with regular layout renderers.

I'm planning to add an additional concept called ambient properties which will help maintain NLog v1 compatibility while being very extensible. Ambient properties are properties that appear as if they were present on all layout renderers and when you actually use them, they add an implicit wrapper. This allows you to write: ${level:uppercase=true:padding=-10} instead of: ${padding:padding=-10:${uppercase:${level}}}

Whenever layout parser encounters an unknown property (such as "uppercase" which doesn't exist on LevelLayoutRenderer anymore) it will look for layout renderers which define [AmbientProperty("UpperCase")] and will instantiate them and use to wrap the original layout renderer:

[
LayoutRenderer("uppercase")]
[AmbientProperty("UpperCase")]
public sealed class UpperCaseLayoutRendererWrapper : WrapperLayoutRendererBase
{
    private bool _upperCase = false;
    public bool UpperCase
    {
        get { return _upperCase; }
        set { _upperCase = value; }
    }
    protected override string Transform(string text)
    {
        return UpperCase ? text.ToUpperInvariant() : text;
    }
}
I have some prototype code on my box and I will check in for others to play with as soon as I get this to a stable state.

What do you think?

Jarek

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Nlog-list mailing list
Nlog-list@...
https://lists.sourceforge.net/lists/listinfo/nlog-list

Re: NLog and ASP.NET / Medium Trust

2008-11-14T20:22:47Z

It's on my todo list for V2. I'm not sure to what extent this is possible, given how reflection-intensive NLog is but I'll give it a try.

Jarek

----- Original Message -----

From: glenn_lanier@...

To: nlog-list@...

Sent: Friday, November 14, 2008 11:00 AM

Subject: [Nlog-list] NLog and ASP.NET / Medium Trust

Is there any way to run NLog in a medium trust environment (ASP.NET)?

--G

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________
Nlog-list mailing list
Nlog-list@...
https://lists.sourceforge.net/lists/listinfo/nlog-list

New feature coming to NLog v2 - wrapper layout renderers

2008-11-14T20:20:55Z

With the code cleanup that's happening in NLog v2 branch I realized that I could easily add a cool feature: Wrapper Layout Renderers which would help me restructure code to make it more maintainable and testable. I'd like to year your opinion about it.

What are Wrapper Layout Renderers (WLRs)?

Similar to wrapper targets, WLRs can modify output of other layout renderers, by doing textual transformations like:

* uppercase/lowercase conversion

* padding, trimming, alignment

* search/replace

* elision of excessive text

* encryption / masking of sensitive information

* cryptographic transformations (calculating MD5, SHA1 hashes, HMAC checksums)

* encoding: base64/uuencode, etc.

etc.

Note that many of those concerns are currently (in NLog v1) handled by LayoutRenderer itself. Being able to separate them into standalone, extensible classes is very convenient as you can add them separately and all existing layout renderers will be able to benefit from them.

So how are they used:

${uppercase:${level}} - will print log level in uppercase

${rot13:${message}} - will print ROT13 "encrypted" message

For config-file-level compatibility, you will still be able to use uppercase,lowercase,padding attributes that you know from NLog v1 directly on layout renderers etc.

To implement a wrapper, all you have to do is to create a class derived from WrapperLayoutRendererBase that overrides the Transform() method and apply the usual LayoutRenderer attribute.

Here's the ROT13 wrapper, which implements Caesar's cipher.

[LayoutRenderer("rot13")]
public sealed class Rot13LayoutRendererWrapper: WrapperLayoutRendererBase
{
    protected override string Transform(string text)
    {
        return DecodeRot13(text);
    }
}

You can of course define public properties as be able to set their values as with regular layout renderers.

I'm planning to add an additional concept called ambient properties which will help maintain NLog v1 compatibility while being very extensible. Ambient properties are properties that appear as if they were present on all layout renderers and when you actually use them, they add an implicit wrapper. This allows you to write: ${level:uppercase=true:padding=-10} instead of: ${padding:padding=-10:${uppercase:${level}}}

Whenever layout parser encounters an unknown property (such as "uppercase" which doesn't exist on LevelLayoutRenderer anymore) it will look for layout renderers which define [AmbientProperty("UpperCase")] and will instantiate them and use to wrap the original layout renderer:

[LayoutRenderer("uppercase")]
[AmbientProperty("UpperCase")]
public sealed class UpperCaseLayoutRendererWrapper : WrapperLayoutRendererBase
{
    private bool _upperCase = false;
    public bool UpperCase
    {
        get { return _upperCase; }
        set { _upperCase = value; }
    }
    protected override string Transform(string text)
    {
        return UpperCase ? text.ToUpperInvariant() : text;
    }
}

I have some prototype code on my box and I will check in for others to play with as soon as I get this to a stable state.

What do you think?

Jarek

NLog and ASP.NET / Medium Trust

2008-11-14T11:00:37Z

Is there any way to run NLog in a medium trust environment (ASP.NET)?

--G

Forwarding adapters for log4net and System.Diagnostics

2008-10-28T02:27:30Z

Hi, a common question is, why so many people are using log4net instead
of NLog. The most common answer is because the library's they use also
using log4net, but they found the configuration of NLog a lot better.

So i suggest that NLog should provide forwarding appends for log4net and
System.Diagnostics out of the box to make it easy to use NLog.

This should be as easy as possible, as example i can look like this:

log4net2NLogForwarder.Enabled = true;

Which will automatically setup log4net to forward all messages to NLog.

Steve

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Nlog-list mailing list
Nlog-list@...
https://lists.sourceforge.net/lists/listinfo/nlog-list

Re: Programatic Configuration of targets and rules

2008-10-15T07:53:52Z

To follow up, I received an answer to this problem (didn't pay attention to the mail headers -- reply was sent off-list).

Essentially, I needed to create a new configuration (or get the current one), make my changes, then assign that configuration BACK to the LogManager.Configuration

NLog.Config.LoggingConfiguration config = new NLog.Config.LoggingConfiguration();

// Do all my stuff here

config.AddTarget(targetDB.Name, targetDB);

config.LoggingRules.Add(new NLog.Config.LoggingRule("*", LogLevel.Trace, targetDB));

// Critical piece!

LogManager.Configuration = config;

--G

On Tue, Oct 7, 2008 at 10:44 AM, Glenn E. Lanier, II <glenn_lanier@...> wrote:

I'm trying to programatically configure a couple of targets and rules (hopefully so I won't have to distribute an NLog.config file) for a WinForms application.

First thing I did was ensure it would all work in the NLog.config file. Then, I tried to build the targets in code, removing the associated lines from the config file.

I have the following code (and I replaced the actual username/password/etc. with placeholder text):

// SQL Database
NLog.Targets.DatabaseTarget targetDB = new NLog.Targets.DatabaseTarget();

NLog.Targets.DatabaseParameterInfo paramDB;
targetDB.DBProvider = "mssql";
targetDB.Name = "db";
targetDB.DBHost = "host";
targetDB.DBDatabase = "dbname";

targetDB.DBUserName = "username";
targetDB.DBPassword = "password";
targetDB.CommandText = "INSERT INTO Logs(LogTime, LogLevel, WindowsUserID, Logger, Message) VALUES (@LogTime, @LogLevel, @WindowsUserID, @Logger, @Message);";

paramDB = new NLog.Targets.DatabaseParameterInfo();
paramDB.Name = "@LogTime";
paramDB.Layout = "${date}";
targetDB.Parameters.Add(paramDB);

paramDB = new NLog.Targets.DatabaseParameterInfo();
paramDB.Name = "@LogLevel";
paramDB.Layout = "${level}";
targetDB.Parameters.Add(paramDB);

paramDB = new NLog.Targets.DatabaseParameterInfo();
paramDB.Name = "@WindowsUserID";
paramDB.Layout = "${windows-identity:domain=false}";
targetDB.Parameters.Add(paramDB);

paramDB = new NLog.Targets.DatabaseParameterInfo();
paramDB.Name = "@Logger";
paramDB.Layout = "${logger}";
targetDB.Parameters.Add(paramDB);

paramDB = new NLog.Targets.DatabaseParameterInfo();
paramDB.Name = "@Message";
paramDB.Layout = "${message}";
targetDB.Parameters.Add(paramDB);

// General Log File
NLog.Targets.FileTarget targetGenFile = new NLog.Targets.FileTarget();
targetGenFile.Name = "generalFile";
targetGenFile.CreateDirs = true;

targetGenFile.FileName = @"${basedir}\logs\${windows-identity:domain=false}\tb911.${date:format=yyyy.MM.dd}.log";
targetGenFile.Layout = "${longdate}|${logger}|${level}|${message}";

// Console
NLog.Targets.ConsoleTarget targetConsole = new NLog.Targets.ConsoleTarget();
targetConsole.Name = "console";
targetConsole.Layout = "${longdate}|${logger}|${level}|${message}";

If I use the SimpleConfigurator:

NLog.Config.SimpleConfigurator.ConfigureForTargetLogging(targetDB, LogLevel.Trace);
NLog.Config.SimpleConfigurator.ConfigureForTargetLogging(targetGenFile, LogLevel.Trace);

NLog.Config.SimpleConfigurator.ConfigureForTargetLogging(targetConsole, LogLevel.Trace);

it appears that the last item in the list is applied, but no others (i.e., this ordering allows the console messages to appear, but no file, and no DB. However, if I move targetDB to be the last command, console messages no longer appear, but DB messages are logged).

So, I searched for a more in-depth article and found one that suggested:

NLog.Config.LoggingConfiguration config = LogManager.Configuration;
if (null == config)

{
config = new NLog.Config.LoggingConfiguration();
}

config.AddTarget(targetDB.Name, targetDB);
config.LoggingRules.Add(new NLog.Config.LoggingRule("*", LogLevel.Trace, targetDB));

config.AddTarget(targetGenFile.Name, targetGenFile);
config.LoggingRules.Add(new NLog.Config.LoggingRule("*", LogLevel.Trace, targetGenFile));

but I'm not have any success there, either.

Can anyone shed some light on how I can configure a SQL database target, a file target, and possibly a console target programatically?

Thanks.
Glenn

glenn_lanier@...

Programatic Configuration of targets and rules

2008-10-07T08:44:48Z

I'm trying to programatically configure a couple of targets and rules (hopefully so I won't have to distribute an NLog.config file) for a WinForms application.

First thing I did was ensure it would all work in the NLog.config file. Then, I tried to build the targets in code, removing the associated lines from the config file.

I have the following code (and I replaced the actual username/password/etc. with placeholder text):

// SQL Database

NLog.Targets.DatabaseTarget targetDB = new NLog.Targets.DatabaseTarget();

NLog.Targets.DatabaseParameterInfo paramDB;

targetDB.DBProvider = "mssql";

targetDB.Name = "db";

targetDB.DBHost = "host";

targetDB.DBDatabase = "dbname";

targetDB.DBUserName = "username";

targetDB.DBPassword = "password";

targetDB.CommandText = "INSERT INTO Logs(LogTime, LogLevel, WindowsUserID, Logger, Message) VALUES (@LogTime, @LogLevel, @WindowsUserID, @Logger, @Message);";