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 ...
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 ...
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.