TAGC / dotnet-setversion

.NET Core CLI tool to update the version information in .NET Core *.csproj files
MIT License
75 stars 16 forks source link

AssemblyVersion and FileVersion are not updated. #2

Closed pms1969 closed 6 years ago

pms1969 commented 7 years ago

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

TAGC commented 7 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")]
pms1969 commented 7 years ago

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.

TAGC commented 6 years ago

Going to close this for now (housekeeping) but can re-open if this is still something you want.