Week of 11th - 15th Oct: Automated build with assembly versioning in .NET

yup BIB, that is one of the objectives among other things. A complete record of all successful dlls ever made and ability to switch among them at will has the potential to save a lot of downtime and possible red faces due to incorrect fixes or bugs

Just wondering ...
Isnt this what creating branches in source control is all about. where once an application or dll is deployed , a copy is frozen and a new branch is started. 

Wrong. In source control concept, you have 3 things. The trunk (current), the tags (released versions, even point versions), and the branches (test versions branched from trunk).

Usually the trunk will be the most current copy that everyone works on. When an application or dll is deployed, the copy is "frozen" and created into a tag, as a released version. The trunk continues on its life. A new branch is not started after a release.

A branch on the other hand means that you're creating a copy of the current trunk, and usually going to experiment with changes that will break the entire build. Hence you don't really want that in the trunk. Because that's where your entire build process reads from and updates from and builds from. And if the current trunk breaks, people are going to find and start hunting you down like dogs. So you branch out the current trunk, make your changes, testing etc etc, and make sure it builds, then merge it back to the trunk. Do note that merging back to the trunk is hard work, as the trunk still progresses, your branch still works on the "older" version of the trunk. So there'll be alot of changes between your branch and trunk. So merging back your changes will require quite a bit of work from your side.

That's the basics of Source Control.

Deployment and testing the current trunk is totally different. I think what Vector is trying to say is during current development of the current trunk, a dll breaks the entire application, and you can find out where went wrong by reverting the dll version and checking the changelogs from the source control. I must agree with BIB. With proper testing facilities like proper unit tests, fxcop, etc, a faulty dll will hardly go undetected during the build process. It's quite rare to actually find a faulty dll without any "errors" from the unit tests, and doesn't work as contracted. But then again, abnormalities do happen, and laziness is the best trait of developers/programmers, so it'll be good to be able to automatically revert back to a working dll version on the testing phase. Do note that you never deploy until it's properly tested and someone decides that it's stable enough to increment a point version and release it.

Usually the build system will work on the trunk and creates the build logs and all. I'm not too sure about assembly versioning in .Net. Usually I'd just change the assembly: AssemblyVersion when I'm about to release. That's all. Is there a better way to do it?

Hi Triplez

this article is about finding that better way.

meanwhile I believe that even after doing unit testing, integration testing and what not (remember tight deadlines and stretched people), mistakes happen and we should have a configurable way to roll back production to a stable state if someone makes a mistake. Analysis can be done later as to which dll was at fault.

And logical errors in a production environment are very hard to catch especially with a patched dll.

lastly, you may do all the testing you want however it is very rare that the UAT environment or the ORT environment will be exactly similar to the production environment. I have been seeing app failures due to infra issues more often than development issues.

hence, versioning is a way which gives a powerful rollback utility to us from an app perspective. I wont go so far as to say its equivalent to db rollback but its something better than nothing :0) and its configuration based rather than file copy based hence less error prone

Vector

blackinkbottle wrote:

CruiseControl http://cruisecontrol.sourceforge.net/ FinalBuilder http://www.atozedsoftware.com/finalbuilder/ Visual Build Pro http://www.kinook.com/VisBuildPro/

I went to look at all 3 of these build systems and interestingly enough, both FinalBuilder and Visual Build Pro doesn't really provide alot of information on it. Both of them are "need-to-pay" applications, and not really what it's supposedly intended to be. It tries to be everything.

Anyway, FinalBuilder seems to be an alternative to the normal batch-file scripting with a nice interface. Well, it looks good, but everything's very visual, and they don't quite put alot of information about the product. Just that it's a build system. That's all.

For Visual Build Pro, it also doesn't really provide much information on the usage of the system, just benefits and marketing stuff. I don't quite like products without detailed technical information on their products. But anyway, it seems to be (correct me if I'm wrong) a visual approach to creating your build system. It depends on plugins and such, and not scripts. And interestingly enough, it doesn't integrate with subversion, so this product won't be something I'll test and try out. But it does integrate directly into Visual Studio .Net 2003, so I'm not too sure how wonderful this is.

Now for CruiseControl. There is a .Net version for it. I've already mentioned the link over here. It's called CruiseControl.Net. (so much for being innovative) It uses XML for your configuration files. The website has quite a bit of information on it. It's FREE. But it isn't quite updated. Last update way back in May I think. Anyway it supports quite a lot of the free and popular source control systems, like subversion, and the popular NAnt and NUnit. So I guess I'll be taking CruiseControl out for a test run. Btw, it comes with a full complete set of build and monitoring system. There's the build server, which runs as a service or a commandline. There's a web application to show the status of the builds. There's webservices to retrieve the status of the builds. There's a task bar app that shows you the status of the build on your desktop. Looks fantastic, and rather a complete solution than the previous two. Though I think the drawback is there's no visual IDE to edit the configuration files, but what the hell, that's what documentations are for. Welcome to the Linux world.

i agree! CruiseControl.NET prob is "a bit" hard to setup due to lack of visual GUI... but provides a lot more flexibility and would not be constrained by the GUI if there is one.

i will revert back more info on the build server things prob on Sunday when i can better find a block of time

I tested out the CruiseControl.NET yesterday. Seems a decent tool. The documentation is accurate to quite an acceptable extent and I was able to extract a solution with 4 subprojects from sourcesafe (on a separate machine network share), and build it in about an hour and a half. After that, setting it to extract and build other projects and solutions is a breeze. It took a further half an hour to figure out the logging mechanism and get the web application going and it looks good. I didnt miss the lack of GUI in the process.

However, something missing is the lack of post build tasks, which are integrated into the system like ftp or xcopy files over. will look into this on monday. tomo I will be consolidating this week's discussion, faq's and shifting the build server posts to the correct thread.

rite now gotta go have some dinner :0) have tried my hand at cooking and now gotta see what my friends have to say about it

Vector