Change Assembly Version in a compiled .NET assembly

Question

Simple question... is there a way to change the Assembly Version of a compiled .NET assembly?

I\'d actually be fine with a way to change the Assembly File Version.

Answer 1

Why do you want to do this? If it's so that another application can use it, you might want to look into assembly binding redirection instead.

Answer 2

VerPatch, as referenced in this answer, is simple and effective.

Answer 3

It sounds like your process is heavy because you have to update multiple AssemblyInfo files. Have you considered sharing the same AssemblyInfo file between projects? Derik Whittaker gives a good example on how to do this.

Once you have a single file, you could then go the extra distance by having a build process update your single AssemblyInfo version using MSBuild or NAnt.

Answer 4

Old topic but here are my 5 dimes...

1. Disassemble

   ildasm my.exe /output:my.il /metadata

2. Edit my.il to change version information. There are several places to look into:

   • major:minor:revision:build - usually one occurrence
   • major.minor.revision.build - several occurrences. The string is found in the comment section after the actual line. The version is a hexadecimal value in a byte array. Example:

.custom instance void [mscorlib]System.Reflection.AssemblyFileVersionAttribute::.ctor(string) = ( 01 00 07 35 2E 31 2E 33 2E 30 00 00 ) // ...5.1.3.0..

3. Edit my.res to change version information. Double click and edit with visual studio. Pretty straight forward procedure.

4. Assemble

   ilasm my.il /res:my.res

Answer 5

If you have formal testing and source control, the process becomes fairly straightforward. It starts with an understanding of who can change the diferent number segments of the version, and when. .net assemblies have 4 number segments (i.e. 1.0.0.1).

The first segment contains the Major Version number. This is set by upper management and indicates a major change in the UI or in the platform of the app. This should always be same number between the assembly version and the file version.

The second segment contains the Minor Version number, also known as the Feature Release number. This is set by Project Management and indicates that new features have been added to the app. This should always be same number between the assembly version and the file version.

The third segment contains the Build number. This is set by the testing group and indicates that the app is ready to be deployed. It is changed before bug fixes are released. When releasing a new build, testing resets the fourth segment to 0. This can be the same number between the assembly version and the file version, but is usually left at 0 for the assembly version to simplify patching existing deployments.

The fourth segment contains the Revision number. This set by the development group whenever they check new code into source control. This number would be included in the file version of the compiled DLL, but not in the assembly version.

I have found that this helps deployers, testers and developers keep track of the latest versions without stepping on each others toes. Unfortunatley, I have also worked with companies that used a static versioning system so that nobody really knew what the latest, best assembly was.

Answer 6

You can use ILMerge:

ILMerge.exe Foo.dll /ver:1.2.3.4 /out:Foo2.dll

A valid reason to do this is to increment the assembly version in a build in you find breaking changes (using NDepend for example). That way if there are no breaking changes the assembly version stays the same, and you can patch released builds easily.

We always increment the file version, and that reflects the build number.