Closed pms1969 closed 6 years ago
I don't think you need to explicitly specify AssemblyVersion
and FileVersion
in .NET Core projects; I omit these assembly attributes and I find that it automatically generates an AssemblyInfo.cs
file in the obj
folder with AssemblyVersion
and FileVersion
set to whatever Version
is, which is set by dotnet-setversion
.
I've just tried this now with one of my projects.
src/PROJECT/Properties/AssemblyInfo.cs
using System.Reflection;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;
// General Information about an assembly is controlled through the following
// set of attributes. Change these attribute values to modify the information
// associated with an assembly.
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("...")]
[assembly: AssemblyProduct("...")]
[assembly: AssemblyTrademark("")]
// Setting ComVisible to false makes the types in this assembly not visible
// to COM components. If you need to access a type in this assembly from
// COM, set the ComVisible attribute to true on that type.
[assembly: ComVisible(false)]
// The following GUID is for the ID of the typelib if this project is exposed to COM
[assembly: Guid("8d58e41c-c2f2-4554-830e-4407f7b6d5ed")]
[assembly: InternalsVisibleTo("...")]
[assembly: InternalsVisibleTo("...")]
Then $dotnet setversion 1.2.3
Then $dotnet build
Then I get this output:
src/PROJECT/obj/Debug/netstandard1.4/COMPANY.PRODUCT.AssemblyInfo.cs
// Generated by the MSBuild WriteCodeFragment class.
using System;
using System.Reflection;
[assembly: System.Reflection.AssemblyCopyrightAttribute("...")]
[assembly: System.Reflection.AssemblyDescriptionAttribute("...")]
[assembly: System.Reflection.AssemblyFileVersionAttribute("1.2.3.0")]
[assembly: System.Reflection.AssemblyInformationalVersionAttribute("1.2.3")]
[assembly: System.Reflection.AssemblyTitleAttribute("...)]
[assembly: System.Reflection.AssemblyVersionAttribute("1.2.3.0")]
Exactly what I ended up discovering. Many teams (and ours included) will oft times set FileVersion and AssemblyVersion to different things, to convey different information. For instance the fileversion might be set to reflect the state of the build, and assemblyversion set to reflect the actual version that is shipping.
Removing the attributes means they get set as you say, but as a future improvement, you might want to add the facility to set them individually. IIRC, there is also a ProductVersion attribute that is handy to set because it's a string, and you can tag your code with the actual git sha, so you have traceability back to the code. That one would be handy too.
Love this solution to the problem. Much applause deserved.
Going to close this for now (housekeeping) but can re-open if this is still something you want.
Let me start by saying this is definitely on the money in terms of solution to the problem.
Having said that, this utility really needs to update the AssemblyVersion and FileVersion too.
I'd propose that you start by changing all 3 at first, and then add parameters to update them all individually if need be.
Cheers