Best Versioning Solution for Assembly Versioning

Question

I am launching a rather complicated project with several independent applications. However, they use several common components. So I have a source tree looking something like below.

• My project
  • Appendix A
  • Shared1
  • Shared2
  • Appendix B
  • Appendix C

All applications have their own MSBuild script, which builds the project and all the resources it needs. I also run these builds on a server with continuous integration into CruiseControl.

When deploying applications, they are deployed to multiple servers to distribute the load. This means that it is extremely important to keep track of which version of the assembly / revision is deployed on each of the different servers (we need to have the current version in the version of the DLL, for example, "1.0.0.68").

It is equally important to be able to recreate the revision / assembly that was built in order to be able to roll back if something did not work out as intended (yes, this happens ...). SourceSafe was used today for version control, but it could be changed if we could provide good reasons for this (SS actually works fine for us so far).

Another principle that we are trying to execute is its only code, which was created and tested by the integration server, which we deploy further.

CrusieControl Label Design

We had several ideas for solving the above. The first one was to build a continuous integration server and locally deploy the project and test it (now it does). As you probably know that a successful build in CruiseControl generates an assembly label, and I assume that we can somehow use it to install the DLL version of our executable files (so assembly label 35 will create a DLL, for example, "1.0 .0.35 ")? The idea was also to use this assembly label to indicate the complete source tree. Then we can probably check this shortcut and recreate the assembly later.

The reason for marking the entire tree is the inclusion of not only the actual application code (that is, in one place in the source tree), but also of all common elements (this is in different places in the tree). Thus, a successful build of “Application A” will be indicated by the entire tree as “ApplicationA35”, for example.

However, when trying to recreate this assembly and install the version of the DLL before deployment, a problem may arise, since then we do not have access to the shortcut of the generated CruiseControl assembly. If all the shortcuts of the CrusieControl assembly were unique for all projects, we could use only the number for marking, but this is not so (both applications A and B could at the same time be in assembly 35), so we must include the name of the application in the label. Therefore, the SourceSafe shortcut is “Application35”. How can I then recreate assembly 34 and install 1.0.0.34 for DLL version numbers after we build assembly 35?

Revision Number Solution

Someone told me that Subversion, for example, creates a version number for the entire source tree at each check - is this the case? Does SourceSafe have something like this? . If so, the idea is to grab this version number when getting the latest information and build on the CruiseControl server. You can then use the version number to set the version number of the DLL (for example, "1.0.0.5678"). I assume that then we could get this specific revision for Subversion, if necessary, and then it will include this application and all the common elements in order to be able to recreate a specific version from the past. Will this work, and can it be achieved using SourceSafe?

Summarize

So, two basic requirements:

• Be able to track the assembly / version number of the assembly and the deployed DLL.
• To be able to rebuild the previous revision / assembly, set the old assembly / revision number in the executable files of this assembly (in order to comply with requirement 1).

So how would you solve this? . What will be your preferred approach and how would you solve it (or do you have a completely different idea?)? ** Nice to give detailed answers. **

Question with a bonus. What is the difference between revision number and build number and when do you really need both?

Answer 1

Your circuit sounds and is achievable in VSS (although I would suggest you consider an alternative, VSS is a really outdated product).

For your assembly “CI” you have to make Versioning take a look at the “MSBuild Community Tasks Project” which has the “Version” tasks. Typically, you will have “Version.txt” in the source tree, and the MSBuild task will increment the number " Release ", while developers will control Major.Minor.Release.Revision numbers (which is how my client wanted it to be). You can use revision if you want.

Then you would have the "FileUpdate" task to edit the AssemblyInfo.cs file with this version, and your EXE and "DLL" would have the desired version.

Finally, the VSSLabel task will appropriately mark all your files.

For your Reconstruction assembly, you would change your Get to get the files from this label, obviously do not complete the Version task (since you are choosing the version to build), and then FileUpdate tasks will use this version number.

Bonus question:

They are all “how you want to use them” - I would use the build number, well, the build number, this is what I would increase. If you use CI, you will have a lot of builds - the vast majority with no intention of ever deploying anywhere.

The primary and secondary ones are self-evident - but the revision that I always used for the Correction indicator. I intend to have a release of "1.3", which would actually be a product with version 1.3.1234.0. While working on 1.4 - I find an error - and you need to install the fix as 1.3.2400.1. Then, when 1.4 is ready - let's say 1.4.3500.0

Answer 2

I need more space than answering, as comments directly allow ...

Thanks! Good answer! What would be the difference, what would be better resolving this using SubVersion for an example? Richard Hallgren (15 hours) ago)

The problems with VSS have nothing to do with this example (although the "Marking" function, which I think is implemented inefficiently ...)

Here are some issues with VSS

1) Branching is fundamentally impossible 2) The usual check is usually not used (I know several people who have had success) 3) the performance is very poor - it is exteremly "chatty" 4) if you do not have a very small repository - it is absolutely unreliable since for most stores this is a ticking time bomb.

For 4, the problem is that VSS is implemented by the entire repository, presented as “flat files” in the file system. When the repository reaches a certain size (I think 4 GB, but I'm not sure about this figure), you have a chance of "corruption". As the size grows, the chances of corruption increase until it becomes almost certain.

So, take a look at the size of your repository - and if you fall into Gigabytes - I strongly recommend that you start planning for replacing VSS.

Regardless - google "VSS Sucks" gives 30K hits ... I think that if you started using the alternative, you will understand that it is worth the effort.

Answer 3

• Sign CC.net Successful Builds
• each project in a solution link with a common solutioninfo.cs file that contains the assembly and version file attributes (delete assemblyinfo.cs from each project)
• Before the assembly has cruise control, run the msbuild regular expression replacement (from the msbuild community tasks) to update the version information using the cc.net assembly label (passed as the parameter for the msbuild task).
• build a solution, run tests, fx cop, etc.
• Optionally return a solution information file

As a result, all assemblies in the published cc.net assembly have the same version numbers that correspond to the label in the source code repository

Answer 4

UppercuT can accomplish all this with a special packaging task to break applications. And to get the source version number, you can think of Subversion.

It is also insanely easy to get started.

http://code.google.com/p/uppercut/

A few good explanations here: UppercuT