SgDotNet
Singapore Professional .NET User Group -For Cool Developers
Forums » .NET Framework » Build & Test Automation » Week of 11th - 15th Oct: Automated build with assembly versioning in .NET

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

rated by 0 users
Not Answered This post has 0 verified answers | 21 Replies | 0 Followers

Top 25 Contributor
354 Posts
Vector posted on 10-10-2004 7:59 PM
Compaction
There is no gene for the human spirit. Gattaca.

All Replies

Top 25 Contributor
354 Posts
Reply
Vector replied on 10-10-2004 8:17 PM
Let me give u guys a background of why this topic came about:

I am currently involved in a project where there are multiple development teams, multiple environments and so on so forth.

Currently we have an automated build system using ofcourse nant, and bat files which do xcopy to take care of deployment.

However, we have not implemented assembly versioning. Hence, the preferred method of debugging after deployment when u know something worked last week but not this week, is to try to copy the dll build that week (sort by date) and try to paste and see how it works. Needless to say, this involves a bit of manual copy-paste, and uses a lot of time.
I was discussing this with another of my friend who told me that in their project, they are using CruiseControl and its fully automated with nice backups of nightly builds and is much more flexible than ours.

I believe that irrespective of the size of the project, small or big, simple or complex, if we can implement a good nightly build process and allow assembly versioning, it will be solving a lot of problems at the root and with a slightly more complexity, will be much more powerful and flexible for the developers who need to work with dll's generated by cross teams but do not want to worry about spending time fixing something which infact was caused due to a change in the dll by the other party.

Hence, for our mutual benefit, I am goind to do some research on this topic, and come up with a good way to do this. I invite you to come with me in this journey and make life better for every .NET developer, build administrator out there by showing them the correct stuff.

Have done some research into assembly versioning yesterday, will post that in the related thread.
There is no gene for the human spirit. Gattaca.
Top 10 Contributor
1,626 Posts
Reply
Firedancer replied on 10-11-2004 4:33 PM
You guys may want to evaluate NAnt. A build tool for .NET
Software development made easy with Paladin RAD Framework. Save some trees, use Stickies.NET
Top 10 Contributor
2,891 Posts
Reply
kitkai replied on 10-11-2004 4:36 PM
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?

Best Regards, Kit Kai, MVP (SharePoint Portal Server)

Top 25 Contributor
354 Posts
Reply
Vector replied on 10-11-2004 6:15 PM
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
There is no gene for the human spirit. Gattaca.
Top 25 Contributor
354 Posts
Reply
Vector replied on 10-11-2004 6:17 PM
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.
There is no gene for the human spirit. Gattaca.
Top 10 Contributor
2,891 Posts
Reply
kitkai replied on 10-11-2004 11:02 PM
 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?

 vector wrote:

I was discussing this with another of my friend who told me that in their project, they are using CruiseControl and its fully automated with nice backups of nightly builds and is much more flexible than ours.

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...

Best Regards, Kit Kai, MVP (SharePoint Portal Server)

Top 25 Contributor
330 Posts
Reply
blackinkbottle replied on 10-12-2004 1:06 AM

Now try to put up some existing practices and given advice to start with, you can read one of MS's early pattern and practices book called "Team Development with Visual Studio® .NET and Visual SourceSafe" esp the Chapter 5 "The Build Process" and "BuildIt—An Automated Build Tool for Visual Studio .NET".

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=94FDB8C8-5A87-4545-AF75-6053F32C7ECA

Other tools

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

blackinkbottle "please polish my crude soul", to the maker of blade the Samurai kneed down and said.
Top 10 Contributor
2,284 Posts
Reply
icelava replied on 10-12-2004 2:08 AM
 Vector wrote:
However, we have not implemented assembly versioning. Hence, the preferred method of debugging after deployment when u know something worked last week but not this week, is to try to copy the dll build that week (sort by date) and try to paste and see how it works. Needless to say, this involves a bit of manual copy-paste, and uses a lot of time.
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.

The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral

Top 25 Contributor
330 Posts
Reply
blackinkbottle replied on 10-12-2004 12:36 PM
i thought vector tries to solve one common scenario: when you deploy assemblies to the site, due to bug goes undetected during integration testing or whatsoever reason something breaks (usually discovered a bit later) but it works before. theoretically this should not happen if the integration testing is very thorough but testing is never complete......Indifferent

So for the purpose of debugging, we want the old assemblies online again and see what causes the bug to manifest...

is that so?

 
blackinkbottle "please polish my crude soul", to the maker of blade the Samurai kneed down and said.
Top 25 Contributor
354 Posts
Reply
Vector replied on 10-12-2004 10:54 PM
Hi Kitkai, 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.
There is no gene for the human spirit. Gattaca.
Top 25 Contributor
354 Posts
Reply
Vector replied on 10-12-2004 10:57 PM
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.

Regards
Rajat

There is no gene for the human spirit. Gattaca.
Top 25 Contributor
354 Posts
Reply
Vector replied on 10-12-2004 11:04 PM
Hi BIB,

cool stuff. I think as part of this article, we need to do an indepth review of the above build servers, and then come up with a recommendation. would you be interested in taking up one tool and doing a review of that.

we can split the reviews this way for different tools and do a final compilation.

For this, would you like to kickstart a discussion in the build server thread about the criteria to evaluate a build server? We can firm up a criteria this week, and measuring mechanism and then go out and do a build server evaluation. I think this way we can create something really valuable for all .NET developers out there.




P.S. On a side note, apart from a developer's curiosity:
If this effort works out, I am also looking at seeing how we can publish this article in the MSDN Asia magazine, ofcourse giving proper credit to all parties involved Smile so maybe we can get to see our names in print Smile . This way we can reach out to more people and really make a difference.
There is no gene for the human spirit. Gattaca.
Top 10 Contributor
2,891 Posts
Reply
kitkai replied on 10-13-2004 9:30 AM
 Vector wrote:

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.

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?

Best Regards, Kit Kai, MVP (SharePoint Portal Server)

Top 25 Contributor
354 Posts
Reply
Vector replied on 10-14-2004 11:01 AM
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.

Regards
Vector
There is no gene for the human spirit. Gattaca.
Page 1 of 2 (22 items) 1 2 Next > | RSS
Copyright SgDotNet 2004-2008
Powered by Community Server (Commercial Edition), by Telligent Systems