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
Nlog-list@...
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 <jaak@...> 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
Nlog-list@...
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
Nlog-list@...
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
Nlog-list@...
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" <lists@...>
To: <nlog-list@...>
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
> Nlog-list@...
> 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
Nlog-list@...
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