views:

230

answers:

1

I always create a MSI file for our web application.There are different states when I build a MSI

  • For system testing on test server after the issues are fixed
  • Another for submitting it to the customer
  • Third is for a hot fix

The current versioning scheme is v3.2.18.18 i.e v x.x.xx.xx

Now how to increment in the above three cases & what is the significance of each number in the versioning scheme.

Also we use Visual studio team foundation server.Is it necessary to keep the numbering scheme of TFS in sync with the version number.We are using VCB (Version Control Build ) as a tool for versioning

+2  A: 

Assembly Version Number

Each assembly has a version number as part of its identity. As such, two assemblies that differ by version number are considered by the runtime to be completely different assemblies. This version number is physically represented as a four-part string with the following format:

major version.minor version.build number.revision

For example, version 1.5.1254.0 indicates 1 as the major version, 5 as the minor version, 1254 as the build number, and 0 as the revision number.

A greater build number indicates a newer version of the same compatible assembly and revision usually indicates minor change (perhaps minor bug). The DLL (assembly) gets its version numbers in compile stage and you cannot change these numbers afterwards (well, this is probably possible but with some low level tools and would probably brake assembly signature if assembly is signed).

If you look at your C:\windows\assembly folder you can see what MS has done. E.g. I have:

  • System.Data 1.0.5000.0 - .NET 1.1
  • System.Data 2.0.0.0 - .NET 2.0
  • System.Data.DataSetExtensions 3.5.0.0 - .NET 3.5

I suggest you don't change your version numbers too often, because if they get referenced from other assemblies you must update the reference also.

Look at When to Change File/Assembly Versions

Petar Repac