Firedancer: You guys may want to evaluate NAnt. A build tool for .NET
Pasted from <http://forums.sgdotnet.org/ShowPost.aspx?PostID=5612>
Vector: Hi Firedancer
we are already assuming NANT to be the base. However, there are new build servers which take nant as the base and abstract away the complexity of a nant script. We are focussing more on those.
Kitkai:
Vector, when u talk about versioning, are u refering to
[assembly: AssemblyVersion("1.0.0.0")]?
or are you refering to the source control versioning which keep a copy of the old dll when u compile a new one
Vector:
not source control, I am talking about the actual assembly version which is deployed.
Source control versioning is for your source file, while assembly versioning is for your end .dll
vector wrote:
I am talking about the actual assembly version which is deployed.
So you specify the version, say 1.0.0.0 in the assembly file right?
Kitkai: For this part, you are actually keeping different versions based on when it is compiled, not the version (1.0.0.0) of the assembly right?
So the discussion should be about the second part, and not about incrementing the version (1.0.*.*) in every build right?
Sorry, kinda confused now...
Vector: every time we build, we will increase the assembly version number.
This will aid in the application using the dll version it was tested against even if the new build has a different assembly which some other app may be using.
Icelava:
Say once you have explicitly versioned your assembly releases, wouldn't it then be an important drive to ensure client programs/assemblies work against explicit versions? So you don't get those breakages?
I don't exactly see how that can be automated, and it's a human decision to say, "let's discard v1.1 of this library and go with v1.2 from now on."
I'd suppose it also means the automated versioning process must deploy assemblies into a directory hierarchy that easily informs of their versions so client developers know which to reference.
Hi icelava,
if we are deploying them into gac, it will automatically treat different versions as different files hence no hierarchical directory structure needs to be maintained.
secondly, i agree with the human decision part. However, our aim is to give the humans the right tools to implement this decision, by changing a simple setting in the config file which may be done remotely. And reverting to the another version is equally simple rather than the tedious and error-prone way of copying / pasting files.
Kitkai: Do you mean, if the ApplicationA is using version 1.0.0.0 of the library, and the library has changes, so library has version 1.0.0.1 now, ApplicationA will not be affected by the new build, but ApplicationNew will be tested against 1.0.0.1.
Qn: If you are building a new app now. The build system u are using is incrementing the version. Assuming the libraries are strongly named, I remember that if you are referencing a strongly named assembly, you have to rereference it if that assembly is being rebuild. Can the build system rereference it? How does it do that?
Vector: Yes appA will not be affected by the new build. AppNew will use the new one.
Please refer to the following post to see how runtime locates the assembly: http://forums.sgdotnet.org/ShowPost.aspx?PostID=5614
My next post in that section will explain what are the various ways by which you can point appA to use the new build. In short, the ways are app.config assemblyBinding settings, publisher policy file in GAC or machine.config assembly rebinding.
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.
Triplez:
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?
Vector: 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