CODEWITHSUNDEEP
.netvisual-studio-2013.net-assembly
Dom Sinclair
Dom Sinclair

Reputation: 2528

Can one strip out the version number information from an application manifest file

I have created an assembly to add additional functionality to a third party vendor's controls (they are aware of this and together we have sorted out licencing issues). What I hadn't realised of course is that visual studio embeds details (and in this case the version numbers ) of all the assemblies that my assembly references in my assembly's manifest file.

I know that I can open this file to view that information with Ildasm.exe, and further research on CodeProject suggests that I can actually go on to edit this file.

So simple question. Can one safely either completely remove the version number information of referenced assemblies or set them to say 0.0.0.0 so that those referenced assemblies become in effect version agnostic?

Thanks

Upvotes: 0

Views: 242

Answers (1)

Hans Passant
Hans Passant

Reputation: 942187

Terminology is important, it does not sound like you are actually talking about an "application manifest file". You cannot see the manifest with ildasm.exe, it only lets you look at the metadata and the IL in a .NET assembly. It, confusingly, labels the metadata as "manifest" in its UI.

And yes, the metadata in a .NET assembly contains version numbers. You'd see something like this with ildasm.exe:

.assembly extern ClassLibrary1
{
  .ver 1:0:5306:9013
}

And no, you can not remove that version number. It was embedded by the compiler when it read the [AssemblyVersion] from the reference assembly you added to your project. That version number is super duper hyper important in .NET, it ensures that the assembly that you load at runtime is identical to the assembly that you compiled your program with. The CLR will category refuse to load the assembly if the version does not match. That is a DLL Hell problem, it causes programs to randomly fail when code in a DLL was changed without you knowing about it and making the necessary corrections in your own code to deal with the changes.

I gave you the worst possible example of an [AssemblyVersion], a version number like 1.0.5306.9013 is an auto-generated version. It changes every time the assembly is rebuilt, even if there were no changes to the code at all. Very hard to deal with if this vendor you are working with does this. If that's the problem you are trying to solve then you should get back in touch with them and convince them that they should not do this. Talk about "semantic versioning".

The CLR insists on an exact version number match but you can convince it that you know better. That requires using <bindingRedirect> in your app.exe.config file.

Upvotes: 5

Related Questions