Vaildating Coding Standards During Build with FxCop
[ Easy Way :
Open a DOS prompt and go to c:\Projects\BuildingSolution
Run c:\devtools\nant\bin\nant.exe -buildfile:secondbuild.build.xml
]
Code reviews are a very important task for a development project of any size. Although following coding standards is important, using code review time to enforce that can be tedious. FxCop, from Microsoft, can help relieve a lot of the time required to enforce coding standards. This can free up the developers to review code, not critique Camel and Pascal case.
The first step is to open FxCop and create an FxCop file.
Open FxCop
Click Project, Add Targets (Ctrl+Shift+A)
Browse to c:\buildingsolution\Latest\buildingbl.dll
Click file, save, and save as c:\projects\buildingsolution\buildingsolution.fxcop
This will create an FxCop file that you will use to validate against the default FxCop standards. FxCop is very flexible and you can customize the rules specific to your coding standards.
Now you can add FxCop to the build. At this point NAnt does not have a specific task for FxCop, but using the <exec task we can easily add FxCop to the build.
<!--
runFxCop will run the fxcop file of the same name as the nant project -->
The <exec task allows you to run any commandline application and collect the output. In this instance, run fxcopcmd.exe, the commandline version of FxCop. The DLL to test is provided, as well as the XML file to output. Again, this file will come into the limelight in a bit.
Create API Documentation
[ Easy Way :
Open a dos prompt, and go to c:\Projects\BuildingSolution
Run c:\devtools\nant\bin\nant.exe -buildfile:thirdbuild.guild.xml
]
The build process creates an intriguing place to create API documentation. The facility to do so is built directly into both NAnt and NDoc. Building documentation on every build may not be appropriate for every project. Rules could easily be applied as to when to create the documentation, such as only on a release build.
For C# projects, the compiler can extract XML documentation at build time. To do so, look at the configuration properties for the BuildingBL project and you can see the XML Documentation Filename property. The project accompanying this article will be set to BuildingBL.xml.
VB .NET developers, on the other hand, have a few steps to get the same documentation. With packages like VB.DOC and VBCommentor you can apply the same API documentation generation.
The XML files used in this article are generated at compile time via VS .NET. By having that setting in the project file, NAnt will also build the solution with the XML file. Building with XML documentation on every build, though, is slower than without. There are a few options to explore. One is using the csc task instead of the solution task, which allows for passing a doc argument. Another would be to use xmlpeek and xmlpoke to modify the proj files and specify a XML documentation filename. The xmlpeek poke task allows you to supply an XPath expression and read values from an xml file. Xmlpoke does the opposite, allowing you to add xml into an xml document at build time.
Since you are generating XML files in the "F5 build" of the project, creating documentation during the build is straightforward. In fact, the whole NDoc task was copied from the NAnt documentation, which, by the way, is very good.
<!--
runCreateDocumentation will create msdn type documentation for the building
solution -->
<targetname="runCreateDocumentation"description="Will create documentation for Buidling
Solution">
The <ndoc> task first wants to know what DLLs and XML files it will be working with. If multiple rounds of documentation needed to be made, this could be fired off in a loop. Then there is a long list of properties. They are all well outlined in the NDoc reference. This will create an MSDN style chm in a /doc directory inside the build folder.
Add the Solution to VSS Source Control
[ Easy Way :
Open a dos prompt, and go to c:\Projects\BuildingSolution
Run c:\devtools\nant\bin\nant.exe -buildfile:fourthbuild.guild.xml
]
The true value of a build process is when used in a team environment. Automating the gathering of everyone's efforts in a predictable way can save developers a lot of manual labor. To accomplish this, Source Code Control is needed. For this article you will be using VSS. If you do not have a VSS server available, NAnt and CruiseControl.NET support a variety of SCC providers, including some well known free packages such as CVS and Subversion.
Right click on the solution in VS .NET and choose "Add Solution To Source Control" (Diagram 1). Choose the root, and do not enter anything in the project text box (Diagram 2). This should create a $/buildingsolution project in VSS. Open the VSS manager (Diagram 3) application, and browse to that project. Inside the BuildingSolution project you should see your .sln file (Diagram 4). Now you should have everything in source control.
The next step is to have the build file get the latest from source control. Coupled with NAnt, you also have NAntContrib. NAntContrib is a collection of add-ins for NAnt, and you will be using the <VSS tasks that come with NAntContrib. To change the build file to get the latest, you need to add one runGetLatest target, which simply calls vssget.
<targetname="runGetLatest">
<vssget
user="user"
password=""
localpath="C:\Projects\BuildingSolution"
recursive="true"
replace="true"
writable="false"
removedeleted="false"
dbpath="\\Hustler\VSS\srcsafe.ini"
path="$/BuildingSolution"
/>
</target>
The vssget task is very straight forward. You will notice that the password is blank. This is because one will not be required for this environment. For this article, NAnt will always be called from an interactive user context, of which you assume this user has access to the VSS database. This will require a build machine be logged in at all times. To avoid this, you could look into running parts of CCNet as a service, and making the applicable changes to the build file to handle permissions.
Add Versioning
[ Easy Way :
Open a dos prompt, and go to c:\Projects\BuildingSolution
Run c:\devtools\nant\bin\nant.exe -buildfile:fifthbuild.guild.xml
]
For this sample build environment, there will be a very simple versioning mechanism. The goals for this article will be to store each sequential build in a corresponding build folder. Versioning with a build system could be a totally separate topic, whichdiscusses items such as labeling in source control, signing assemblies with versions, the GAC, the different versions that can be assigned, etc. This set of tools can support a very sophisticated system of versioning, so you will only really be limited by your imagination.
For simple versioning, you will use the <version task in NAntContrib. You will start by creating a text file called build.number in c:\projects\buildingsolution, and add 1.0.0.1 to the file. Then add the following to your build file.
This will cause the build.number file to have its file version incremented by one, and the value of the version to be put into the NAnt property sys.version. Now, you can change your output directories to use ${sys.version} to make sure each build gets its own unique home. The latest version will always be in the latest folder, and each version will stay archived in its own folder with its associated test results. You could easily add a label in source control to mark this exact build, which would tie your builds to your source. You can find this in the NAntContrib package.
Use CruiseControl.NET To Monitor and Track Changes
[ Easy Way
Edit c:\devtools\ccnet\service\ccnet.config and change where its commented to change
Double click on StartCCNet.bat
]
So far you have created a repeatable build process that tracks its own life through the results of some unit tests. The next section of the article will discuss how to easily track and report on these tests, and the rest of the build. Enter CruiseControl.NET.
CCNet is used for Continuous Integration ("CI"). CI is a set of concepts around a continuous period of integrating code. This means that source control is constantly monitored, and as a file is checked in, a build will be triggered. This allows developers to know the results of their change within minutes of check in, and can very easily get back into that code.
CCNet will also report and track the results of the build, unit tests, and FxCop via a number of mediums.
You will use CCNet to watch VSS and build for you and then report and track the build results. To do so, you will need to configure a few parts of CCNet. You will first need to configure a server instance to watch and initialize builds. If you wish to enable Web reporting, you will also need to configure a virtual directory in IIS. It is also possible to track builds through HTML e-mails and receive build notifications through a SysTray notification application.
Once you extract CCNet, there are a few files that must be updated for your solution. In the c:\devtools\ccnet\server file you will see a ccnet-example.config file. This is the starter file that should be saved to ccnet.config for CCNet to work. The changes that were made to the file were the following:
Changed the scc to vss via the CCNet confluence site example
Changed the merge task to <merge><files><file></files></merge>
Changed the <file> element to match my file structure
Changed the build executable to my nant path
Changed the build basedirectory, buildfile, and target to match
Changed the <xmllogger><logFile> to match my structure
Once the changes are made, and many times before, click on StartCcnet.Bat to start CCNet. The first time you start CCNet it should find modifications and perform the first automated build. If all goes well, you should get an e-mail, and the Web site should be updated. You might be thinking Web site? That hasn't been set up yet.
The ccnet.config file is telling the server to copy results to ../web/log, which is where the Web site will look for its data. So the next thing to do is configure a virtual directory to point to c:\devtools\ccnet\web. To do so, navigate to c:\devtools\ccnet, and right click on the Web directory. Choose the Web sharing tab, and share the folder as ccnet.
Once you have done that, open a browser to http://localhost/ccnet and you should see the results of your first build. You can see that CCNet gathers the FxCop and unit test results. This information is also e-mailed to an address from the ccnet.config file. This allows for an active build process that notifies you when it breaks. Each developer can work in his own sandbox and write unit tests for his own parts of the system, and when he check in all of his tests will be run. Combine that with unit tests that handle integration testing and even the smallest change can trigger a cascading effect of failed tests. These tests could fail within minutes of the code being checked in, making it easier for a developer to find and fix the problem.
The CCNet Web site also allows viewing of the FxCop results. A link to the FxCop screen can be found in the upper right hand side of the project page. CCNet also provides a dashboard site that works as a central management point for a number of CCNet server applications. CCNet has a number of options available. Read the documentation for more information.
NOTE: Since this article was written, a new version of CCNet has been released. The new version of CCNet introduces some new features that allow CCNet to actually build your app, such as a task to get your source from source control, as well as buil and unit test, thus replacing some of the tasks NAnt handles. NAnt is much more flexible for the actual build, but if you are not taking advantage of some of the advanced features NAnt offers, you may want to look at the possibility of CCNet for the build process, as well as the continuous integration and reporting engine.
Conclusion
This article has outlined a suite of tools that can be used to make your own build environment. The sample here is very basic, but outlines some important aspects of builds. As you can see, a build process can be much more than F5. Giving automated reporting on unit tests, helping with code reviews, and adding reliability to your builds are just a few benefits to a well architected build process, and the tools outlined here give you the reliability and power to realize many more.
About the Author
Aaron Junod is a seasoned software developer with a diverse background in software development and hardware architecture, on projects ranging from one user, to over a million. Aaron is currently working as a software designer and developer for a transaction processing company specializing in employee benefits. Aaron is a Microsoft Certified Professional, and has been involved in architecting solutions for the Insurance and Human Resources industries, delivering web, windows, and device solutions. You can read more about Aaron, as well as contact him at http://blog.iceglue.com.
In the second part of his series on building N-tier web applications using ASP.NET 2.0 and SQL Server 2005, Thiru Thangarathinam covers the business logic and user interface layers. In the process, he also examines some new features in ASP.NET 2.0 that greatly simplify the development process.
[Read This Article][Top]
Code reusuability is one of the major goals of any good object-oriented programmer. While the ASP.NET framework has made code reusuability easier and more elegant than it was in classic ASP, one area where reusuability could be improved is at the UI level. This article outlines a technique that you can use in ASP.NET 1.x that allows every page in your web application to inherit not only the functionality of a base page, but its UI as well.
[Read This Article][Top]
In this article, Gayan Peiris looks at creating an ASP.NET web application that will display the usage details of a selected SharePoint site. Building such an application enables SharePoint administrators to gather all SharePoint usage data from a central location. [Read This Article][Top]
In this article, Gayan Peiris examines using the SharePoint Object Model
to access SharePoint site information from an ASP.NET web application.
It should be of particular interest to SharePoint administrators who
can use the included code as a starting point for development of
their own web-based SharePoint administration application.
[Read This Article][Top]
In this article, David Every outlines a step-by-step account of how he solved the problems he encountered while implementing an auto-deployment process. He also describes how to create a stable process for automated remote .NET deployment featuring "side-by-side" capability. [Read This Article][Top]
Most default SharePoint Server Web Parts can be connected across organizations. The third article in this series shows how to develop connectable Web Parts that consume information provided by other Web Parts. [Read This Article][Top]
Automatic daily builds is a well known software engineering best practice. This article introduces a strategy for implementing and promoting daily builds and offers tips and tricks for preventing and fixing breaks. [Read This Article][Top]
Building an application can be more than pressing F5. With an increasing
number of quality packages being released, developers for the .NET platform now have options to create a very sophisticated build process. Aaron Junod describes a sample build environment and shows how a number of tools can work together to make reliable, predictable, and value-added builds. [Read This Article][Top]
The first part of this three part series walks through the process of creating a mobile blog application using a BASIC development environment for Palm OS devices called NS Basic.
Subsequent articles will focus on synchronizing the data to the desktop using C# and creating an installer. [Read This Article][Top]
This short article provides source code for a classic ASP online database functions testing application and shows how to configure and use the tool for either SQL Server or Oracle. [Read This Article][Top]
Mailing List
Want to receive email when the next article is published? Just Click Here to sign up.
