Compiling Code with NAnt, go.bat is Your Friend
// September 14th, 2008 // Programming
As I’ve mentioned before, in the root of our “dev tree” (ie trunk) we have a “go.bat” file which compiles are code. As part of the code police, it’s a sly way of trying to impose code that doesn’t break the build, but it’s actually quite effective.
We take a NetBeans approach using NAnt to control the whole build (from compilation to deployment), and use go.bat to run the same build files that CruiseControl.Net uses (but not the complete set, as on a local pc you don’t need to deploy etc…).
Some may ask what’s wrong with simply “building” using Visual Studio. Nothing, and I still do so when writing code. However before doing a commit, or after a merge I use go.bat because of the following:
- It’s stricter when using MSBuild to compile the code (in terms of missing files such as images, or css, warnings as errors etc…) than doing so via Visual Studio. This ensures redundant files and references are removed, and that compilation errors won’t occur.
- We run aspnet_compiler as part of the build to ensure all .aspx, .ascx etc… pages compile properly. This reduces the chances of run time errors.
- Unit tests are run after the compilation. This ensures any changes that have been made haven’t broken any test cases. This reduces the chances of regression bugs being introduced.
- Anyone that doesn’t want to open Visual Studio (people working on css/javascript etc…) can build the application easily without having to open Visual Studio.
- If go.bat builds successfully, you can be confident it will build successfully with CruiseControl.Net. This is important as you need to be confident the changes you’ve made are ok before you make a commit to source control.
There is also a go.deploy.bat file. This is for mimicking a CruiseControl.Net deployment, but to a folder on your local machine. I use this for a number of things:
- For creating test builds to deploy onto our scalability rig.
- If there have been changes to the NAnt build files, or ccnet.config. I can do a dummy deploy and check that the build is ok before commiting the changes.
- For doing routine checks of the build and seeing the output.
And there you have it. No one f**ks with the code police. This guy broke some unit tests. As you’ll be able to see, to be in the code police you either have to have a goatie, or be a hard looking skinhead.
More next time on ReSharper templates, FxCop rules, and StyleCop.
