Considerations for implementing trace facilities in release builds of .NET applications

Vagif Abilov

Rate me:

3.61/5 (11 votes)

4 Nov 20029 min read

112.3K

What is the best technique to produce trace output in release build of .NET application, i.e. when application is shipped to a customer or runs in a production environment? The article discusses pros and cons of standard .NET trace facilities, and presents some alternatives.

Alternatives

Members may post updates or alternatives to this current article in order to show different approaches or add new features.

No alternatives have been posted.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

Written By

Vagif Abilov

Architect Miles AS

Norway

Vagif Abilov is a Russian/Norwegian software developer and architect working for Miles. He has more than twenty years of programming experience that includes various programming languages, currently using mostly C# and F#.

Vagif writes articles and speaks at user group sessions and conferences. He is a contributor and maintainer of several open source projects, including Simple.Data OData adapter, Simple.OData.Client and MongOData.

Considerations for implementing trace facilities in release builds of .NET applications

Alternatives

License

Comments and Discussions