We have our AssemblyVersion and AssemblyFileVersion attributes in a separate properties file. This is because they are "linked" between all the projects and are updated by the build server. We don't want to have to manually update versions after every build or release.
AssemblyInfo.cs:
[assembly: AssemblyTitle("MyProductTitle")]
[assembly: AssemblyCulture("")]
[assembly: Guid("579eb194-08f1-44fc-9422-21aaf6cb2963")]
AssemblyVersionInfo.cs:
[assembly: AssemblyFileVersion("0.0.14056.19")]
[assembly: AssemblyVersion("0.0.0.0")]
The problem is that our build server complains with the following warning for each project:
CA1016 : Microsoft.Design : Add an AssemblyVersion attribute to 'MyProduct.dll'.
When building the projects locally, the actually DLL files in bin have all the version numbers applied (file property dialog):
When looking at the project properties in Visual Studio, the version info is not detected in Assembly Info:
My guess is that this is due to AssemblyVersion and AssemblyFileVersion not residing in AssemblyInfo.cs.
Is there any way to "include" the custom AssemblyVersionInfo.cs file?
More than one thing going wrong here:
The dialog is pretty empty because it strictly looks at the AssemblyInfo.cs file for attributes. And will write them to that file if you enter a version number. Using a separate file is not a great idea.
The Windows "Details" property sheet is agnostic of .NET, it only displays the content of the unmanaged version resource in the file. Which is only indirectly related to the attributes in your C# source code, the C# compiler auto-generates the unmanaged version resource from the attributes. Sadly, the super-important [AssemblyVersion] number is not displayed in this dialog, XP was the last Windows version that could still display it.
You probably got CA1016 because you left the version number at 0.
Windows not displaying the [AssemblyVersion] is not a good reason to skip the attribute. If it is important to you to see it in the property sheet then simply make the [AssemblyFileVersion] the same as the [AssemblyVersion]. Do keep in mind what it used for, if you change the [AssemblyVersion] then all of the projects that have a reference to the assembly need to be recompiled.
There's bad history between the Windows and DevDiv groups at Microsoft, I don't want to get into the details of it. Let's just say that Windows does very little to accommodate .NET. It is up to us to work around this.
Related
I'm working on a project where plugins are deployed in DLL's.
When deploying a DLL, it gets locked by the application. To update it I have to change the name of the DLL (since I can't overwrite the original), and update the app database to use the new version of the library.
I'd like to make this as automated as possible.
In AssemblyInfo, I've set the [assembly: AssemblyVersion("1.0.*")] to automatically increment.
I'm hoping that I can pull this version into the project properties Assembly Name, so that it automatically appends the version number to the generated DLL.
Is this possible at all with VS/C#?
Following Hans advice that the file renaming can't be done during the build, I've decided to rename the file after build.
In order to find the version number quickly for renaming, I've removed the AssemblyFileVersion line from the AssemblyInfo file. Which will set the file version to the version number. Automatically Update Assembly File Version
After building the DLL I can check the file properties, where the version number will be listed as File version under the details tab.
I'll copy the version number from here and append it to the DLL name.
I have a solution with multiple projects and created a SharedAssemblyInfo (as links) so that I can share the version number across all the projects. I also have an AssemblyInfo file in each project for the assemblyName and guid. When I build and run locally it runs fine. When I attempt to build, MSBuild throws an exception when it tried to retrieve the version number. I'm getting a null reference exception when I tried to retrieve the assembly version. Any ideas?
So I figured out the error. In tfs, where I create a new build definition, you can specify a build template. We are using our own custom build template, which I don't have access to see what its doing but I'm able to use it. In the process section there was a line called "Increment version number". This was by default selected as true. When I set this to false I can get it to build now. I assume our custom build template must be specifying this action to use the assemblyinfo.cs file. So I could modify our build template to look for version number in sharedassemblyinfo.cs or in my case I just marked it not to increment version number.
When building an application using a traditional language, the build version number was embedded as the version in the compiled executable (right-click properties, and there the version would be). It was a magical and beautiful time as this process was automatic, and in sync with whatever the current publish build in your project was. (when i state build in reference to version number, what I actually mean is the entire version string Major.Minor.Build.Revision )
Now, Visual Studio still has the same feature, except there doesn't seem to be any way to naturally embed this into the published executable. It does a fine job at using it to name the folder where the build is located, but the exe inside ALWAYS reads v1.0.0.0, even after modifying the AssemblyInfo file with the following line :
<Assembly: AssemblyVersion("1.0.*")>
.. which only sets arbitrary numbers based on the current time for the masked parts, and even still, this isn't what shows as the file version..
When attempting to change the AssemblyFileVersion value, from
<Assembly: AssemblyFileVersion("1.0.0.0")>
to :
<Assembly: AssemblyFileVersion("1.0.*")>
It is unsupported. Even if it did work, this would NEVER match the build of the project :
How can I embed the above number in an automatic way into the compiled executable so that the version shows up here :
Notice how neither the file version or the product version reflect neither the AssemblyVersion or the version in build settings.
If you are using the 'Release' exe,then you should change the version in:
Project > Properties > Assembly Information
I made a change to an ancillary DLL that my project uses, built it of course, renamed the legacy DLL to *.dll_old, and copy and pasted in the new version of the DLL to that same folder.
However, when I then ran the app that uses the DLL, it errored out with:
"An expected error has occurred...bla bla bla...or select Details for more information.
I did select Details, and saw:
TypeLoadException
File or assembly name <name of the DLL, which I just replaced>
Version=<bla>
Culture=neutral
PublicKeyToken=null, or one of its dependencies, was not found.
UPDATE
Based on the comments, I guess there's more to replacing a DLL than one might expect. I don't know if this is significant or not, I thought replacing a DLL would be like replacing an EXE, but maybe not: the DLL project's AssemblyInfo.cs says,
[assembly: AssemblyVersion("1.3.*")] // used by .NET framework only
[assembly: AssemblyFileVersion("1.3.0.308")] // File Version - increment here
[assembly: AssemblyInformationalVersion("6.3.0")] // Product version - set to current IEQ system
...and the Version in the err msg is "1.3.3889.27539"
Do I need to update one of these lines (I would guess the middle one, if so) to that value (1.3.3889.27539)? Or...???
UPDATE
So since the .DLL is not strongly named, I tried simply removing the reference (to the old .DLL) in the project that uses the DLL and then adding it back again (same file name, different version). I see, though, that updating the .DLL does not change the version numbers shown above - IOW, the AssemblyInfo.cs does not get updated when building. Should it? Do I need to manually update these vals?
It seems that types inside your original DLL were referenced by your EXE file. WHen you replaced it with your own version the references were messed. The EXE file contains metadata table with a list of types, methods, properties, etc that it references and exact version of the assemble expected. Providing something else even if everything was the same but the version number is simply not the same thing. That is why you are getting the exception.
UPDATE: Yes it is possible. However it involves creating a manifest file. For more information check this MSDN web site on Redirecting Assembly Versions. Also, keep in mind that only strongly signed assemblies can be redirected. Non-signed assemblies will be ignored.
In the assemblyInfo.cs I have AssemblyVersion and AssemblyFileVersion.
Normally I just increment the AssemblyVersion like this.
1st digit: Major change
2nd digit: Minor change
3rd digit: bug fixes
4rd digit: Subversion revision number
However, I am wondering what is the AssemblyFileVersion for, and when do I need to increment. Should it be the same as the assemblyVersion?
Should I just comment it out, if I am not using it?
Many thanks for any advice,
AssemblyVersion is used by the .NET class loader and identifies the .NET version of the assembly. AssemblyFileVersion represents the File Version contained in a standard VERSION_INFO block of a Windows PE file...in other words, it represents the file version as seen in the file properties dialog.
If you omit the AssemblyFileVersion, the compiler will default it to be the same as the AssemblyVersion.
Generally the file version is more precise than the assembly version. Per example: System.Windows.Form.dll - Assembly Version: 2.0.0.0, File Version: 2.0.50727.3053.
The assembly version is an important information when it is time to load an assembly.
So, if you find a small bug in one of you referenced assembly. You fix the bug, update the file version but you keep the same assembly version. The advantage: you dont have to relink your references to this assembly to the new version and with the file version you can know the current revision of your file.
Installers will use AssemblyFileVersion to determine whether to overwrite a file based on version.
It's important to note that changing the AssemblyVersion for an assembly that implements serialization has some serious consequences when trying to deserialize from a previous version.
I am not an expert, and I may not be referencing an expert, but from what I have understood, broadly speaking the AssemblyVersion is about the 'interface' -> what the assembly does, backward compatibility etc. And the AssemblyFileVersion is more to do with implementation, which build etc.
Use AssemblyVersion attribute to specify "Last Compatible-To" version and AssemblyFileVersion attribute to specify the build version.”
-> http://www.shitalshah.com/blog/IsJeffRichterScrewingUpTheNetVersioning.aspx
//Oh, and another thing.
There are certain circumstances (about which I'm not too clear, as I've only heard about them but not actually experienced them) where if you try to update an application with dll's in the GAC, old versions of dlls won't be overwritten by new versions with the same Assembly Version number, unless the File Version has changed. (Is that sentence complicated enough? It's late here...)
AssemblyFileVersion is used to set the version info in the Win32 resource in your
binary, the one you see if you open the properties window for the file
in Explorer.