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.
Related
I'm working on a mod for Mount and Blade 2 and having an issue with how it's dealing with modification.
Mods are used like plug-in and they are composed of one or a few DLLs, that can reference other DLLs.
The issue is that i reference a library NHloader version 1.0.1 in my own DLL and when testing on my own everything is perfect.
When i load with other mods it becomes a bit more messy as sometime NHloader is used by another mod and the version referenced is the 1.0.0, that lacks some of the methods i use.
So right now it's a bit random, as the first mod to load also load it's version of NHloader with no way to specify that i only want the latest version loaded. Is there a way to force this behavior? Or at least ensure that my DLL will only use the correct version or later?
Thank you for reading.
As you can see in the following picture when you create a project of type Analyzer with Code Fix (.NET Standard) using VS 2017, in the properties tab of the project there is package version, assembly version and assembly file version.
Are those 3 versions related together or not? Also, as I make changes in the project how am I supposed to change the versions number? For instance, if I fix a bug, if I add a new rule, etc.
Are those 3 versions related together or not? Also, as I make changes in the project how am I supposed to change the versions number? For instance, if I fix a bug, if I add a new rule, etc.
Before answering this question, we need to know some info about the AssemblyVersionand AssemblyFileVersion.
Assembly Version: This is the version that .Net looks at during run-time for loading packages and finding types.
Assembly File Version: This defines the version reported by the OS to other applications like Windows Explorer.
You can see the Rémy van Duijkeren`s answer for some more details.
However, NuGet doesn’t use either of these. It uses a third versioning attribute: AssemblyInformationalVersion - the Product version of the assembly.
It uses this attribute because nothing else seems to care about it. The informational version isn’t used by the OS or by .Net, which means it’s available for NuGet to claim. But this versioning attribute was removed in the AssemblyInfo.cs file, because they don’t apply to semantic versioning.
When you are in the project of type Analyzer with Code Fix (.NET Standard) using VS 2017, those attributes settings has moved into the .csproj file. By default they don't show up but you can discover them from Visual Studio 2017 in the project properties Package tab:
Once saved those values can be found in MyProject.csproj:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net461</TargetFramework>
<Version>1.2.3.4</Version>
<Authors>Author 1</Authors>
<Company>Company XYZ</Company>
<Product>Product 2</Product>
<PackageId>MyApp</PackageId>
<AssemblyVersion>2.0.0.0</AssemblyVersion>
<FileVersion>3.0.0.0</FileVersion>
<NeutralLanguage>en</NeutralLanguage>
<Description>Description here</Description>
<Copyright>Copyright</Copyright>
<PackageLicenseUrl>License URL</PackageLicenseUrl>
<PackageProjectUrl>Project URL</PackageProjectUrl>
<PackageIconUrl>Icon URL</PackageIconUrl>
<RepositoryUrl>Repo URL</RepositoryUrl>
<RepositoryType>Repo type</RepositoryType>
<PackageTags>Tags</PackageTags>
<PackageReleaseNotes>Release</PackageReleaseNotes>
</PropertyGroup>
In the file explorer properties information tab, Version is shown as "Product version", which is used by NuGet. Just like the versioning attribute: AssemblyInformationalVersion.
So, if you fix a bug or add a new rule, you can change the package version for shipping new package.
major is incremented for a breaking change, minor for a change that
is backwards compatible and patch for bug fixes.
As to whether it needs to be modified the versions number for Assembly Versions, you can refer to this document for some more details.
Hope this helps.
In my solution I have a third-party A.dll with another B.dll(Specific version = true) dependency. But I have older version of B.dll and it goes with error:
Could not load file or assembly 'B, Version=2.0.0.1, ...'
but i have B.dll with little older version (2.0.0.0)
so how can i solve my problem? How to loose version depenceny? Force to look for older in not exists?
AND what is important A and B are third-party. So i can't change it.
Just define a version redirection in your app.config.
See here.
Or you can set the 'Specific version' option to false.
Of course, both options only work as long as there is no breaking change...
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.
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.