NLog refactoring / cleanup / directions ideas

[Jaroslaw Kowalski]

I am thinking of serious cleanup of NLog code base and build process to make
entire product easier to maintain in the future. This will form a basis of
NLog 2.0:

Here are the directions I'm thinking about:

1. Replace NDoc(which is essentially dead) with Sandcastle
(http://blogs.msdn.com/sandcastle/) for documentation generation.

2. Deprecate/Remove suppport .NET 1.x and .NET Compact Framework 1.x (NLog
1.0 will stay around to support older frameworks, I don't want legacy code
to remain there in NLog 2.0).

3. No more "universal" release (which was built with .NET 1.0 and used many
runtime tricks to detect and compensate for platform differences). Instead
targeted builds will be available for all frameworks.

4. Add generics to Logger (replace generated code with generic methods) -
will maintain source-level compatibility but will break IL-level
compatibility.

5. Move to a single build system (MSBuild). Remove NAnt, VS2003 and compact
framework projects. Some simple msbuild hackery will be used to produce
builds for all supported platforms.

6. Evaluate the possibility of using LINQ-style lambdas to do deferred
evaluation of layouts and/or log messages, something like:

for (int i = 0; i < 10; ++i)
{
    logger.Debug(()=> "asdasd" + i);     // lambda here will not be
evaluated if logging is disabled for Debug level.
}

Rationale: Many people still try to use string concatenation (which kills
performance) instead of String.Format-style when passing log messages.
Lambdas have the potential to make that easier while maitaining high speed.

7. Simplify website/documentation generation. Sandcastle may help here.

I would like to hear your comments - do you think the above list is
reasonable? What directions would you like NLog 2.x to evolve in?

Jarek


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Nlog-list mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nlog-list

[mattman206]

I think that all of these items are excellent ideas.  NLog is a great library and I'd hate to see it fade out of popularity because it hasn't kept up.  Sure it hasn't had any updates for the last year, but that's because it didn't need any.  The performance increases would be nice too.

Can we also get a VS2008 solution? :)  (Small thing, I know)

I'm not sure if DocProject is quite ready for production use, but that might be something to look into.
http://www.codeplex.com/DocProject

Irregardless of DocProject, the Sandcastle Help File Builder will be useful as it tries to duplicate the NDoc GUI.
http://www.codeplex.com/SHFB

I've done some similar changes on other projects and would love to help out with this.  Let me know :)

-Matt

On Wed, Jun 4, 2008 at 10:52 PM, Jaroslaw Kowalski <[hidden email]> wrote:

I am thinking of serious cleanup of NLog code base and build process to make
entire product easier to maintain in the future. This will form a basis of
NLog 2.0:

Here are the directions I'm thinking about:

1. Replace NDoc(which is essentially dead) with Sandcastle
(http://blogs.msdn.com/sandcastle/) for documentation generation.

2. Deprecate/Remove suppport .NET 1.x and .NET Compact Framework 1.x (NLog
1.0 will stay around to support older frameworks, I don't want legacy code
to remain there in NLog 2.0).

3. No more "universal" release (which was built with .NET 1.0 and used many
runtime tricks to detect and compensate for platform differences). Instead
targeted builds will be available for all frameworks.

4. Add generics to Logger (replace generated code with generic methods) -
will maintain source-level compatibility but will break IL-level
compatibility.

5. Move to a single build system (MSBuild). Remove NAnt, VS2003 and compact
framework projects. Some simple msbuild hackery will be used to produce
builds for all supported platforms.

6. Evaluate the possibility of using LINQ-style lambdas to do deferred
evaluation of layouts and/or log messages, something like:

for (int i = 0; i < 10; ++i)
{
   logger.Debug(()=> "asdasd" + i);     // lambda here will not be
evaluated if logging is disabled for Debug level.
}

Rationale: Many people still try to use string concatenation (which kills
performance) instead of String.Format-style when passing log messages.
Lambdas have the potential to make that easier while maitaining high speed.

7. Simplify website/documentation generation. Sandcastle may help here.

I would like to hear your comments - do you think the above list is
reasonable? What directions would you like NLog 2.x to evolve in?

Jarek


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Nlog-list mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nlog-list

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Nlog-list mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nlog-list

[Steve Wagner]

Hallo Jaroslaw,

first i have a suggestion. Currently there is a forum and a
Mailing-list. I for myself prefer Mailing lists instead of Forums
because i can read the messages in the style i like and not the style
the forum administrator prefer :-) So i suggest to go the mono way
http://go-mono.com/forums/#nabble-f1367 and integrate the Mailing list
as Forum on the page. So there is only on source to communicate but two
way to do it.

Possibly it is also a good advice to move the project and homepage to
CodePlex and leave only the Mailinglist and Sourcecode on SF.

I also think this are all good ideas and hope to see this nice lib go
forward.

Steve

Jaroslaw Kowalski schrieb:
> I am thinking of serious cleanup of NLog code base and build process to make
> entire product easier to maintain in the future. This will form a basis of
> NLog 2.0:

> Here are the directions I'm thinking about:
>
> 1. Replace NDoc(which is essentially dead) with Sandcastle
> (http://blogs.msdn.com/sandcastle/) for documentation generation.
>
> 2. Deprecate/Remove suppport .NET 1.x and .NET Compact Framework 1.x (NLog
> 1.0 will stay around to support older frameworks, I don't want legacy code
> to remain there in NLog 2.0).
>
> 3. No more "universal" release (which was built with .NET 1.0 and used many
> runtime tricks to detect and compensate for platform differences). Instead
> targeted builds will be available for all frameworks.
>
> 4. Add generics to Logger (replace generated code with generic methods) -
> will maintain source-level compatibility but will break IL-level
> compatibility.
>
> 5. Move to a single build system (MSBuild). Remove NAnt, VS2003 and compact
> framework projects. Some simple msbuild hackery will be used to produce
> builds for all supported platforms.
>
> 6. Evaluate the possibility of using LINQ-style lambdas to do deferred
> evaluation of layouts and/or log messages, something like:
>
> for (int i = 0; i < 10; ++i)
> {
>     logger.Debug(()=> "asdasd" + i);     // lambda here will not be
> evaluated if logging is disabled for Debug level.
> }
>
> Rationale: Many people still try to use string concatenation (which kills
> performance) instead of String.Format-style when passing log messages.
> Lambdas have the potential to make that easier while maitaining high speed.
>
> 7. Simplify website/documentation generation. Sandcastle may help here.
>
> I would like to hear your comments - do you think the above list is
> reasonable? What directions would you like NLog 2.x to evolve in?

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Nlog-list mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nlog-list

[KlaWill]

Hello Jaroslaw, Hello all others who reading this

First of all; Nlog is great and works very well
Thanks Jaruslav!!

The only enemy of a good thing is a better thing.
Therefore i have a few suggestions:

is it possible to make nlogviewer more complete ?
(Have a look at tracetool. realy great for tracing, not so for logging)
- logging complete objects

The rest is said before, nothing to comment.
For me it seem that all Ideas are making sens.

Best wishes
Klaus

[Jaroslaw Kowalski]

Hi!

I've just created a new NLog2 branch and checked in first, very experimental
but pretty big refactoring and cleanup.

The code is at http://svn.nlog-project.org/repos/nlog/branches/NLog2/
The change can be viewer:
http://svn.nlog-project.org/viewvc/viewvc.cgi?view=rev&revision=511

There are several breaking changes in the API (although compensating for
them should be as simple as changing several using statements and using
generics instead of untyped collections in most cases).
Configuration file format and option have remained unchanged (and I have no
plans to touch this area). As a result upgrading from NLog v1 should be
pretty smooth for users who are not using configuration API.
Logging API should remain source-level compatible, but not IL-compatible.
There is one minor addition to allow lambdas to be specified to produce
deferred logging messages.

Code base has been reduced by 12% (down from 3879K to 3417K), mostly thanks
to using generics and other .NET 2.0 features which helper remove certain
pieces of generated code.
We are now at revision 0x200 - seems like a good start for V2?

Please let me know what you think.

Jarek

Checkin comment:

* configuration-file-based usage remains unchanged
* API refactored in many ways (some breaking changes)
    * moved certain classes from NLog namespace to NLog.Config,
NLog.Targets, NLog.Layouts, NLog.LayoutRenderers
    * renamed Layout to SimpleLayout
    * turned ILayout interface into Layout base class
    * removed CompiledLayout pattern all over the place
    * removed [AcceptsLayout] by replacing all string properties with actual
Layouts (added implicit conversion from string makes the usage clean)
    * removed [AcceptsCondition] by replacing all string properties with
ConditionExpression (added implicit conversion from string makes the usage
clean)
    * removed most of platform detection logic (will use conditional
compilation exclusively in v2)
    * removed NLog.*Factory classes and aggregated all factories
NLog.Config.NLogFactories using common interface
    * removed *Collection and *Dictionary classes and replaced them with
generics
    * public APIs that used to expose *Collection are now ICollection<T> or
IList<T>
    * refactored LogEventInfo into multiple classes for formatted and
unformatted events
    * added delayed evaluation delegate (LogMessageDelegate) and added
logging method overloads that accept it:
         Usage (C# 3.0 using lambda syntax):
             logger.Info(() => "this is my message, x=" + x + ", y=" + y);
         Usage (C# 2.0 using inline delegate syntax)
             logger.Info(delegate { return "this is my message, x=" + x + ",
y=" + y });
    * removed VS 2003 project files
    * regenerated Logger.cs to use generics
* removed support for .NET 1.x and .NET CF 1.x and many hacks and
workarounds to support them

This is intermediate and somewhat experimental check-in in a separate
branch, some things are broken:
    * Documentation generation with NDoc is broken at this point - will be
replaced with Sandcastle
    * NAnt scripts are currently broken (use MSBuild 3.5). NAnt support will
most like be completely removed for V2

All unit tests are passing (using NUnit 2.4.7).

----- Original Message -----
From: "Steve Wagner" <[hidden email]>
To: <[hidden email]>
Sent: Thursday, June 05, 2008 3:58 AM
Subject: Re: [Nlog-list] NLog refactoring / cleanup / directions ideas

> Hallo Jaroslaw,
>
> first i have a suggestion. Currently there is a forum and a
> Mailing-list. I for myself prefer Mailing lists instead of Forums
> because i can read the messages in the style i like and not the style
> the forum administrator prefer :-) So i suggest to go the mono way
> http://go-mono.com/forums/#nabble-f1367 and integrate the Mailing list
> as Forum on the page. So there is only on source to communicate but two
> way to do it.
>
> Possibly it is also a good advice to move the project and homepage to
> CodePlex and leave only the Mailinglist and Sourcecode on SF.
>
> I also think this are all good ideas and hope to see this nice lib go
> forward.
>
> Steve
>
> Jaroslaw Kowalski schrieb:
>> I am thinking of serious cleanup of NLog code base and build process to
>> make
>> entire product easier to maintain in the future. This will form a basis
>> of
>> NLog 2.0:
>
>> Here are the directions I'm thinking about:
>>
>> 1. Replace NDoc(which is essentially dead) with Sandcastle
>> (http://blogs.msdn.com/sandcastle/) for documentation generation.
>>
>> 2. Deprecate/Remove suppport .NET 1.x and .NET Compact Framework 1.x
>> (NLog
>> 1.0 will stay around to support older frameworks, I don't want legacy
>> code
>> to remain there in NLog 2.0).
>>
>> 3. No more "universal" release (which was built with .NET 1.0 and used
>> many
>> runtime tricks to detect and compensate for platform differences).
>> Instead
>> targeted builds will be available for all frameworks.
>>
>> 4. Add generics to Logger (replace generated code with generic methods) -
>> will maintain source-level compatibility but will break IL-level
>> compatibility.
>>
>> 5. Move to a single build system (MSBuild). Remove NAnt, VS2003 and
>> compact
>> framework projects. Some simple msbuild hackery will be used to produce
>> builds for all supported platforms.
>>
>> 6. Evaluate the possibility of using LINQ-style lambdas to do deferred
>> evaluation of layouts and/or log messages, something like:
>>
>> for (int i = 0; i < 10; ++i)
>> {
>>     logger.Debug(()=> "asdasd" + i);     // lambda here will not be
>> evaluated if logging is disabled for Debug level.
>> }
>>
>> Rationale: Many people still try to use string concatenation (which kills
>> performance) instead of String.Format-style when passing log messages.
>> Lambdas have the potential to make that easier while maitaining high
>> speed.
>>
>> 7. Simplify website/documentation generation. Sandcastle may help here.
>>
>> I would like to hear your comments - do you think the above list is
>> reasonable? What directions would you like NLog 2.x to evolve in?
>
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Nlog-list mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nlog-list
>
>

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Nlog-list mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nlog-list

[ifwdev]

I have just started using NLog and I think these changes are great!  Thank you for producing such a high quality project!

[Karl S]

I really like the direction of v2, especially the lamda evaluations. Very nice - how are things coming on getting a beta level release?

Jaroslaw_Kowalski wrote:

I am thinking of serious cleanup of NLog code base and build process to make
entire product easier to maintain in the future. This will form a basis of
NLog 2.0:

Here are the directions I'm thinking about:

1. Replace NDoc(which is essentially dead) with Sandcastle
(http://blogs.msdn.com/sandcastle/) for documentation generation.

2. Deprecate/Remove suppport .NET 1.x and .NET Compact Framework 1.x (NLog
1.0 will stay around to support older frameworks, I don't want legacy code
to remain there in NLog 2.0).

3. No more "universal" release (which was built with .NET 1.0 and used many
runtime tricks to detect and compensate for platform differences). Instead
targeted builds will be available for all frameworks.

4. Add generics to Logger (replace generated code with generic methods) -
will maintain source-level compatibility but will break IL-level
compatibility.

5. Move to a single build system (MSBuild). Remove NAnt, VS2003 and compact
framework projects. Some simple msbuild hackery will be used to produce
builds for all supported platforms.

6. Evaluate the possibility of using LINQ-style lambdas to do deferred
evaluation of layouts and/or log messages, something like:

for (int i = 0; i < 10; ++i)
{
    logger.Debug(()=> "asdasd" + i);     // lambda here will not be
evaluated if logging is disabled for Debug level.
}

Rationale: Many people still try to use string concatenation (which kills
performance) instead of String.Format-style when passing log messages.
Lambdas have the potential to make that easier while maitaining high speed.

7. Simplify website/documentation generation. Sandcastle may help here.

I would like to hear your comments - do you think the above list is
reasonable? What directions would you like NLog 2.x to evolve in?

Jarek


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Nlog-list mailing list
[e-mail]
https://lists.sourceforge.net/lists/listinfo/nlog-list

[Adam Hearn]

NLog2 has a lot of promise but it looks like it might be a long time before release or maybe will never be released? Is there any chance of an update?

[muromec]

Hi

I would like to share an idea of tracking buffered messages with AspNetBufferingTarget by some id.
nlog hasn't such feature yet, and i had to wrote it by myself.
I think it would be very useful for others if they can save messages in buffer marked with the same string id, coz it would help to find the whole request history by this id in file (for example at our company we write simple log finder wich shows whole request history founded by some search conditions so user can see request flow)  and it also be helpful in same way for db logging.
I think it may be done with just 2 things to do:
1) on beginrequest initilize some propertie with provided id (for example time-base calculated).
2) It also need to add some special layout-render parameter with format abilities for this to set in config.
By the way id of the threads is not a solution coz after some amount of time its produces same ids
So what you think about it?

[Rod Spencer]

You may want to investigate C# 4.0.  
See article: http://software.intel.com/en-us/blogs/2009/03/30/the-c-programming-language-version-40/

primarily Dynamic Typed Objects and Optional and Named Parameters.

[nabbed]

I would love to see the database target specify a ConnectionStringName property which points to an existing connectionstring in the connectionstrings section. It would save a little bit of web config.