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.7K

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.

No downloads associated with this content

By viewing downloads associated with this article you agree to the Terms of Service and the article's licence.

If a file you wish to view isn't highlighted, and is a text file (not binary), please let us know and we'll add colourisation support for it.

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

License

Comments and Discussions