Elegant, Efficient and Scheduled Builds of .NET Applications

Introduction

Compiler Warnings (First Level)

   catch (Exception ThisException)
   {
      Response.Write ("There seems to be some problem. My method 
                       threw an exception");      
   }

The above block would raise a compiler warning since the identifier ThisException has never been used. Perhaps you can temporarily dump into

     Debug.Write("The class TestClass had a problem. Here are the details " 
                  +ThisException.StackTrace + " and " +
                  ThisException.Message);

     //Debug.Write is available from System.Diagnostics namespace.

The above block would be passed by the compiler without any errors/warnings. But this as it is does not serve any purpose, All these Debug.Write statements are visible within Microsoft Visual Studio .NET Debug window. And when the application rolls out into production environment, we can change the Project Build Option into Release when all Debug Symbols would be removed and a cleaner and smaller Assembly would be generated by the compiler.

There are some options like amount of ConnectionOpen and ConnectionCloses, FileStreamsOpen and FileStreamsClosed, depending upon the nature of the application itself. In these cases, you can use Tracing. Tracing, has effects only when it has been enabled from Web.Config and works till the level that it has been configured to. So if you would like to monitor number of database connections being opened and closed or amount of FileOpens and Closes as these are bit blocking operations involving more resources, you can use Tracing as it would generate enough logging information that you can use to detect, diagnose and assess the situation.

Tracing is the biggest gift in ASP.NET application compared to any other framework and is beyond the scope of discussion in this small article. Perhaps the following article is a good point of understanding on Tracing in ASP.NET. An Article on Tracing in ASPFree.com

Well! Let's come back to our original discussions. Normally it is better to heed to the compiler warnings other than ignoring them. A warning actually stands for some potential problem. Like an un-initialized object, if when used, may cause a System.NullReferenceException. Possibly, that is why, there is a compiler option like 'Treat Warnings As Errors', which when enabled, will halt compilation, even if warnings are encountered. By default, this option is off.

Compiler Warnings (with XML Document Option)

  <summary>
     Some sample Summary Comments Tag. Visual Studio .NET normally uses this
     to show you a description of what the method does that carries the
     summary comments.
  </summary>   

Perhaps there are a lot more Documentation Comments that needs to be used for generating a documentation comments for an application. A complete documentation of documentation comments is available from the following MSDN URL:

• http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csref/html/vcoriXMLDocumentation.asp

Changing Configurations:

Perhaps while we roll out the web application into production, it is normally a recommended option to change the Build Configuration to Release mode, since in Release configuration, a lot of debug information are not saved and the compiler tries to make application assembly as compact and as fast as possible, as far as my little knowledge could analyze.Perhaps in larger organizations, there would be seperate teams to manage this Release Configuration. But in smaller organizations, it would be the responsibility of the development team itself to manage Debug and Release Configurations. Isn't it?

Scheduled Builds

Perhaps once we configure our web application in Release Mode, we can save this Solution file and use an automated Batch File or a freeware tool like BuildIt, which can automatically take a latest version from SourceControl also and do a complete Build and sending the BuildReports to us. I had an opportunity to download BuildIt and play around it from the following URL and our team really liked it:

• http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/tdlg_app.asp

I think for internal test builds, the above Scheduled Builds would really be useful. Once all BuildIt reports are ok, during final deployment, a personnel can verify everything and transfer the same to the production. Isn't it?

Conclusion

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