Nabble - NLog Forum

Server logging window..

2008-07-03T04:51:38Z

Hi, im trying to use a RichTextBox as a server logging window, to show what messages are being recieved from the clients and any important actions the server is taking...

Now I am making use of the different logging levels, Trace, Error, Fatal, etc.. But I want to be able to switch between the levels of output programmatically at runtime. Any idea's how to do this?

Also I am currently specifying a form that doesn't exist, so NLog is creating one, can I specify the start X & Y coords along with size somehow when it is created?

Finally, the logging on the most "verbose" level, will log a LOT of data, for obvious reasons the string in the textbox could get VERY large.. I only really want to show/care about the most recent say... 300 logs. Is there any way in which I could add this functionality in?

Re: Changing FileName programmatically

2008-07-02T14:17:46Z

I did it this way

config = new LoggingConfiguration();

FileTarget fileTarget = new FileTarget();
config.AddTarget("file", fileTarget);

fileTarget.Layout = "${longdate}|${level}|${callsite}|${message}";
fileTarget.FileName = String.Format("${{basedir}}/{0}.log", filename);

LoggingRule rule = new LoggingRule("*", LogLevel.Debug, fileTarget);
config.LoggingRules.Add(rule);

LogManager.Configuration = config;

where filename is passed into the method as a parameter

Hope this is what you're looking for

Nlog unhandled exception

2008-07-02T10:25:53Z

Unhandled Exception: System.TypeInitializationException: The type initializer fo
r 'AIVCombinator.Program' threw an exception. ---> NLog.Config.NLogConfiguration
Exception: Exception occured when loading configuration from 'NLog.config' ---> System.ArgumentException: Target Mail not found.
at NLog.TargetFactory.CreateTarget(String name)
at NLog.Config.XmlLoggingConfiguration.ConfigureTargetsFromElement(XmlElement
element)
at NLog.Config.XmlLoggingConfiguration.ConfigureFromXmlElement(XmlElement con
figElement, String baseDirectory)
at NLog.Config.XmlLoggingConfiguration.ConfigureFromFile(String fileName)
at NLog.Config.XmlLoggingConfiguration..ctor(String fileName, Boolean ignoreE
rrors)

I got this exception while using nlog can anyone provide some information about this ASAP

LayoutRenderer variable information in asp.net

2008-07-01T07:41:09Z

Hi -

How does one find the values nLog is using for special variables such as {$basedir}, ${asp-application}, etc? Basically any of the variables defined at http://www.nlog-project.org/layoutrenderers.html?

I'm in ASP.NET and would like to write out specific information to an aspx page to help troubleshoot.

Thanks -

Re: Stopping/Starting NLog on runtime?

2008-06-25T05:04:31Z

I used the LogManager.DisableLogging() and LogManager.EnableLogging() functions to turn off and on logging. It works fine.

Regards,
Gabor

Seperate or multiple Console type logging

2008-06-25T04:39:25Z

Hello,

is it possible to write logs into seperate consoles ( as writing logs to seperate files )? I'd like to run my own console application and log events to another console window. Therefore i should start a new console and make it the target for NLog.
Thank you!

Regards,
Gabor

Re: General NLog Console Target in Windows Service

2008-06-25T04:35:59Z

Hello,

thank you for your reply.
Unfortunately changing the service compilation to Console Application instead of Windows Application did not help. There was no console output while the service was running.
I changed the service to a console application and it works now.

Best Regards,
Gabor

Initial NLog v2 checkin (was Re: NLog refactoring / cleanup / directions ideas)

2008-06-21T23:24:41Z

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

From forum: NLog-list

how to store log in database (oracle ) help me out plz

2008-06-19T15:47:39Z

when i store log in a file i add thz
Set env.variable(NLOG_GLOBAL_CONFIG_FILE) as
Right Click-> My Computer -> Properties -> Advanced -> Environment Variables

i have database xml configuration file .
i want to ask u that for data base i have setvariable(NLOG_GLOBAL_CONFIG_database)

Re: how to store log in database(oracle) plz help me out

2008-06-19T15:31:00Z

Re: how to store log in database(oracle) plz help me out

2008-06-17T19:17:01Z

Have you tried to use the config from this page?

http://www.nlog-project.org/target.Database.html

There are actually two config files which were contributed by NLog users.

how to store log in database(oracle) plz help me out

2008-06-17T08:40:28Z

how to store log in database(oracle) plz help me out
as soon as possible my id is shah_khubab@yahoo.cm

regards
khubab.

Re: Performance Enhancements

2008-06-16T07:38:36Z

Hello,

For those interested, here is the patch for the below mentioned items.

NLog-1.0\src\NLog\Targets\Wrappers\AsyncTargetWrapper.cs
208c208
< } while (_flushAll);
---
> } while (_flushAll || RequestQueue.RequestCount > BatchSize);

NLog-1.0\src\NLog\Win32\Targets\MSMQ.cs
189a190,224

>         /// Writes the specified array of logging events to a queue specified in the Queue
>         /// parameter.
>         /// </summary>
>         /// <param name="logEvents">An array of <see cref="LogEventInfo "/> objects.</param>
>         /// <remarks>
>         /// This function override increases performance of batches by not having to
>         /// check the queues existence and connect to it for each logEvent.
>         /// </remarks>
>         protected internal override void Write(LogEventInfo[] logEvents)
>         {
>             if (_queue == null)
>                 return;
>
>             if (!MessageQueue.Exists(Queue))
>             {
>                 if (CreateQueueIfNotExists)
>                     MessageQueue.Create(Queue);
>                 else
>                     return;
>             }
>
>             using (MessageQueue mq = new MessageQueue(Queue))
>             {
>                 foreach (LogEventInfo logEvent in logEvents)
>                 {
>                     Message msg = PrepareMessage(logEvent);
>                     if (msg != null)
>                     {
>                         mq.Send(msg);
>                     }
>                 }
>             }
>         }
>
>         /// <summary>

Thanks,

Jake Milnes

----- Original Message ----
From: Jake Milnes <jacob_milnes@...>
To: nlog-list@...
Sent: Tuesday, June 3, 2008 10:24:25 AM
Subject: Performance Enhancements

Hello,

For a new project of ours, we looked at several different logging frameworks and decided on using NLog. Thanks for making NLog great!

We made a couple of minor performance enhancements to speed up our particular usage of NLog. I would like to find out if others are interested in these performance enhancements or if anyone sees any problems with these:

1. Added Write(LogEvent[]) override to the MSMQ class. This removes the overhead of checking for the queue's existence, connecting and disconnecting for every insert if you are batching the inserts (e.g. through a buffered wrapper or async wrapper).
2. Updated the Async wrapper class so that it doesn't go back to sleep after processing a callback if there are still enough items on the queue for a full batch.

We did some decent performance testing benchmarks before and after, and saw significant gains in the applicable test cases (by roughly a factor of 5). I can provide more detail on the performance test if someone is truly interested (the test results currently are not written up for release).

Thanks,

Jake Milnes

From forum: NLog-list

Re: exceptions problems..

2008-06-13T11:18:31Z

Re: Recommended roundrobin database and failover setup?

2008-06-13T07:35:53Z

That is not bad, but I'm not convinced that the performance will be much improved.
In the WAN scenario the cost you're paying is probably the cost of network round-trip that is needed to execute each command.

It's not easy to optimize that, but you may want to have a database target that batches requests:
instead of a single DbCommand that will be executed for each request, you will send multiple commands separated by semicolons. The reason why I'm saying it is not easy with parameters. You have to find a way to rewrite query string to use a different set of parameters for each log entry.

In your case you'll have to produce a query text like:

EXECUTE [LoggerDB].[dbo].[usp_InsertAppLog] @AppName1, @LogDate1, ..., @SerializedObject1;
EXECUTE [LoggerDB].[dbo].[usp_InsertAppLog] @AppName2, @LogDate2, ..., @SerializedObject2;
EXECUTE [LoggerDB].[dbo].[usp_InsertAppLog] @AppName3, @LogDate3, ..., @SerializedObject3;

EXECUTE [LoggerDB].[dbo].[usp_InsertAppLog] @AppNameN, @LogDateN, ..., @SerializedObjectN

Note that the number of parameters will grow very quickly and you can easily exceed a protocol limit, so at some point you will have to flush whatever query you have built and send it down to the database.

I think that batching 10 inserts at a time should give you about 10x speedup (if network is the limiting factor). This won't scale linearly, so you should experiment with the number of batched commands.

I'm thinking of adding batching to future versions of NLog. In the meantime, feel free to make a copy of Database target (Database.cs) and add batching using the approach I described and experiment. I am very interested in the results you can achieve.

Re: Recommended roundrobin database and failover setup?

2008-06-13T07:20:25Z

To clarify something. Each of the database targets is exactly the same. I did this so that NLog would use multiple connections. Is this good or bad?

Re: Recommended roundrobin database and failover setup?

2008-06-13T07:15:32Z

Here are the details of the database target. It's in a dedicated logging database. The server is very powerful, but there is a WAN between my test machine and the database server.

<target xsi:type="Database" keepConnection="true" dbProvider="sqlserver" dbHost="xxxx" dbDatabase="xxxx" dbUserName="xxxx" dbPassword="xxxx" >
<commandText>
EXECUTE [LoggerDB].[dbo].[usp_InsertAppLog]
@AppName
,@AppFilter
,@LogDate
,@Message
,@Level
,@Priority
,@UserName
,@UserIP
,@MachineIP
,@LogGuid
,@Details
,@SerializedObject
</commandText>
<parameter name="@AppName" layout="${event-context:item=AppName}" />
<parameter name="@AppFilter" layout="${event-context:item=AppFilter}" />
<parameter name="@LogDate" layout="${event-context:item=LogDate}" />
<parameter name="@Message" layout="${message}" />
<parameter name="@Level" layout="${level:uppercase=true}" />
<parameter name="@Priority" layout="${event-context:item=Priority}" />
<parameter name="@UserName" layout="${event-context:item=UserName}" />
<parameter name="@UserIP" layout="${event-context:item=UserIP}" />
<parameter name="@MachineIP" layout="${event-context:item=MachineIP}" />
<parameter name="@LogGuid" layout="${event-context:item=LogGUID}" />
<parameter name="@Details" layout="${event-context:item=Details}" />
<parameter name="@SerializedObject" layout="${event-context:item=SerializedObject}" />
</target>

Re: Recommended roundrobin database and failover setup?

2008-06-13T06:53:47Z

First approach is better, because you are defining each target only once. As a result, there will be one instance of an open file which is better than 3 file handles competing to write to the same file.

But if you want to have a separate file for each database - then go ahead with approach #2.

10 minutes/10K records - that is 1000 records per minute or 16 per second. That seems slow, but not that unusual if there is a network latency, database load, heavy indexes on the table or something similar.

Can you send details of your <Database> target setup, so that we can take a look?

Re: exceptions problems..

2008-06-13T06:40:34Z

Please send your config file. Looks like something is missing there.

Chainsaw and Exception Problems

2008-06-12T16:39:39Z

Hi, i am try to send my exceptions by upd with ChainSaw, if send log to file works ok but when i try to send by ChainSaw Upd i got this excepcion

System.TypeInitializationException was unhandled
Message="The type initializer for 'pruebalogg.Program' threw an exception."
Source="pruebalogg"
TypeName="pruebalogg.Program"
StackTrace:
at pruebalogg.Program.Main(String[] args)
at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
InnerException: System.NullReferenceException
Message="Object reference not set to an instance of an object."
Source="NLog"
StackTrace:
at NLog.Targets.NLogViewerTarget.get_Renderer()
at NLog.Targets.NLogViewerTarget.get_IncludeSourceInfo()
at NLog.Targets.NLogViewerTarget.NeedsStackTrace()
at NLog.Internal.TargetWithFilterChain.PrecalculateNeedsStackTrace()
at NLog.LogFactory.GetTargetsByLevelForLogger(String name, LoggingRuleCollection rules, TargetWithFilterChain[] targetsByLevel, TargetWithFilterChain[] lastTargetsByLevel)
at NLog.LogFactory.GetTargetsByLevelForLogger(String name, LoggingRuleCollection rules, TargetWithFilterChain[] targetsByLevel, TargetWithFilterChain[] lastTargetsByLevel)
at NLog.LogFactory.GetConfigurationForLogger(String name, LoggingConfiguration config)
at NLog.LogFactory.GetLogger(LoggerCacheKey cacheKey)
at NLog.LogFactory.GetLogger(String name)
at NLog.LogManager.GetCurrentClassLogger()
at pruebalogg.Program..cctor() in C:\Users\Dany\Documents\Visual Studio 2008\Projects\pruebalogg\pruebalogg\Program.cs:line 11
InnerException:

? Ideas ?

Recommended roundrobin database and failover setup?

2008-06-12T15:01:31Z

My target structure is like this

<target name="ApplicationTarget" xsi:type="FallbackGroup" returnToFirstOnSuccess="true" >
<target xsi:type="RoundRobinGroup" >
<target xsi:type="Database" keepConnection="true"/>
<target xsi:type="Database" keepConnection="true"/>
<target xsi:type="Database" keepConnection="true"/>
..... (etc a copy for each separate connection)
</target> RoundRobinGroup
<target name="fileAppTarget" xsi:type="File" />
</target> FallbackGroup

So NLog should attempt to write to the database using 1 of 3 connections. If that fails it will write to the file system. Does this look right? Or should it be more like this?

<target name="ApplicationTarget" xsi:type="RoundRobinGroup" >

<target xsi:type="FallbackGroup" returnToFirstOnSuccess="true" >
<target xsi:type="Database" keepConnection="true"/>
<target name="fileAppTarget" xsi:type="File" />
</target> FallbackGroup

<target xsi:type="FallbackGroup" returnToFirstOnSuccess="true" >
<target xsi:type="Database" keepConnection="true"/>
<target name="fileAppTarget" xsi:type="File" />
</target> FallbackGroup

<target xsi:type="FallbackGroup" returnToFirstOnSuccess="true" >
<target xsi:type="Database" keepConnection="true"/>
<target name="fileAppTarget" xsi:type="File" />
</target> FallbackGroup

</target> RoundRobinGroup

Also it's taking 10 minutes to write 10K test log entries using the database. Does this seem reasonable? Is there some NLog tuning I could do?

Thanks,
Jamison

Re: SQL Data Table Qusetion

2008-06-12T08:53:22Z

Here's what I'm using. The table will support multiple applications. Columns are ordered by their likeliness to be searched on. Any critiques are welcome.

Create table [dbo].[Log]
(
[LogID] Bigint Identity NOT NULL,
[AppName] Varchar(50) NOT NULL,
[AppFilter] Varchar(100) NOT NULL,
[LogDate] Datetime NOT NULL,
[Message] Nvarchar(255) NOT NULL,
[Level] Varchar(5) NOT NULL,
[Priority] Tinyint NOT NULL,
[UserName] Varchar(100) NOT NULL,
[UserIP] Varchar(39) NOT NULL,
[MachineIP] Varchar(39) NOT NULL,
[LogEntered] Datetime Constraint [DF_Log_LogEntered] Default GetUtcDate() NOT NULL,
[LogGuid] Uniqueidentifier Constraint [DF_Log_LogGuid] Default NewID() NOT NULL, Constraint [UNQ_Log_LogGuid] UNIQUE ([LogGuid]),
[Details] Ntext NOT NULL,
[SerializedObject] xml NOT NULL,
Primary Key ([LogID])
)

Re: event-context needs more documentation

2008-06-10T14:05:04Z

Remarks:

Use event-context to add runtime values to your log.

Example:

Within your application you must manually build the LogEventInfo object. This allows you to set the context variables.

dim theLog As NLog.Logger = NLog.LogManager.GetCurrentClassLogger()
Dim theEvent As NLog.LogEventInfo
theEvent = New NLog.LogEventInfo(LogLevel.Trace, "", "This is my log message")
theEvent.Context("CustomerID") = 12345
theEvent.Context("CustomerName") = "Acme, Inc."
theLog.Log(theEvent)

Now the event-context layout render gives you access to these values.

${event-context:item=CustomerID} -- produces "12345"
${event-context:item=CustomerName} -- produces "Acme, Inc."

event-context needs more documentation

2008-06-09T13:02:02Z

I spent all morning looking for a way to add CustomerID, CustomerName, and etc to my logging. I finally stumbled on to this page. And realized event-context would handle what I needed.

My $0.02,
Jamie

Edit: I replied with possible text. Giving a little back. J

Re: Nlog with Log2Console

2008-06-06T22:46:09Z

I haven't used Log2Console, but NLog has a target called Chainsaw (given that L2C is supposed to be compatible with Chainsaw you may want to give it a try).

http://www.nlog-project.org/target.Chainsaw.html

Nlog with Log2Console

2008-06-06T21:57:39Z

Hi, i am new in Nlog i need configure Nlog with Log2Console.. ?
Ideas ?

Re: NLogViewer

2008-06-06T13:48:37Z

Log2Console http://www.codeplex.com/log2console

Re: NLog refactoring / cleanup / directions ideas

2008-06-05T23:39:13Z

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

From forum: NLog-list

Re: NLog refactoring / cleanup / directions ideas

2008-06-05T03:58:56Z

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?

From forum: NLog-list

Re: NLog refactoring / cleanup / directions ideas

2008-06-05T03:54:59Z

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

From forum: NLog-list

Re: NLog in Asp.net 3.5

2008-06-04T22:44:46Z

Now its working perfectly without restarting evertime, many thanks
your tips are very helpfull for my..

NLog refactoring / cleanup / directions ideas

2008-06-04T19:52:10Z

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

From forum: NLog-list

Re: NLog in Asp.net 3.5

2008-06-04T18:23:24Z

Yes. That should help.

Re: NLog in Asp.net 3.5

2008-06-04T07:25:48Z

no autoreload its not in !
should i insert autoreload ?

<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<targets>
</targets>

<rules>
</rules>
</nlog>

Re: NLog in Asp.net 3.5

2008-06-04T07:12:51Z

Are you using autoReload="true" at the top of your config file?

It should look like that:

<nlog autoReload="true">
...
</nlog>

Without that, the only way to reload the configuration is to restart the application (which is exactly what happens when you re-deploy NLog.dll).