Question

I am having a problem getting the AssemblyVersion to be different from the AssemblyFileVersion attributes in a class library I am working on.

So, I've tried creating an empty (apart from Class1.cs) class library to see if it's a setting somewhere, but I get the same behaviour.

It seems the AssemblyVersion attribute is just being ignored.

Here is the relevant bit from my AssemblyInfo.cs file ...

[assembly: AssemblyVersion("0.1")]
[assembly: AssemblyFileVersion("1.1.0.9")]

and here is how things look in windows explorer ...

Windows Explorer Screen Grab

Is there a setting somewhere that controls this?

EDIT: I've found one file where there is a difference, so it's not windows explorer showing the same value for two different fields, it's something to do with the way the DLL is generated from the compiler/linker ...

enter image description here

Was it helpful?

Solution

The key problem here is that Windows doesn't know anything about attributes in a managed program. It reads the unmanaged file version resource. The one that's embedded in a C# assembly with the /win32res compile option. The compiler auto-generates it by default if you don't use that option, using the assembly attribute values you specified in AssemblyInfo.cs to create the resource.

But an unmanaged file version resource doesn't have a standard field to specify anything like [AssemblyVersion]. Only [AssemblyFileVersion]. The compiler actually emits it, the version resource is extensible. But Windows XP was the last version that still displays these custom fields. You can see that unmanaged resource by opening the assembly in Visual Studio with File + Open + File.

Yes, lame and annoying. The Windows group at MS does not like to cater to managed code.

OTHER TIPS

Right, found the answer :-)

You need to edit AssemblyInfo.cs and add the following at the bottom

[assembly: AssemblyInformationalVersion("4.4.4.4")]

That value is displayed in the "Product version" in explorer. The AssemblyInformationalVersion is optional. If not given, the AssemblyVersion is used.

More information on this topic is here

Checking on my PC, it actually works ok.

Explorer:

enter image description here

Properties:

enter image description here

Others which are different are: enter image description here

My windows explorer.exe version is 6.1.7601.17567 if that helps. Windows 7 SP1

Testing this myself on Visual Studio with

[assembly: AssemblyVersion("2.2.2.2")]
[assembly: AssemblyFileVersion("3.3.3.3")]

Gave the result: enter image description here So looks like Visual Studio is doing something wrong here.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top