Sdk: Question: How to version dotnet core assemblies

[tarekgh]

@golfguy0082 commented on Thu Apr 06 2017

Forgive me if this is not the appropriate channel for a question. I'm trying to figure out how to version (and retrieve) assembly versions in dotnet core (both build and publish). I've been searching for documentation on this, but I've come up empty. Below are some things I've tried.

dotnet publish /p:Version=3.0.1 (where [Version]3.0.0[/Version] is defined in csproj)
dotnet publish --version-suffix 1 (where [VersionPrefix]3.0[/VersionPrefix] is defined in csproj)

I'm retrieving the version using the following code:
typeof(ReflectionUtils).GetTypeInfo().Assembly.GetName().Version.ToString();
ReflectionUtils is an arbitrary type in my assembly. No matter what I try, the version retrieved from the above line shows 3.0.0.0.

Can anyone point out what I'm doing wrong, or point me in the direction of a page that explains some of this stuff more fully?

---

@karelz commented on Thu Apr 06 2017

The code you wrote inspects assembly version (defined by AssemblyVersionAttribute).

I don't know what the dotnet publish command sets in csproj -- @davkean any idea where to direct the question? Does it belong into your area or CLI area?

---

@tarekgh commented on Fri Apr 07 2017

CC @weshaggard @ericstj

@golfguy0082 net core is not different than the full framework. you can set the assembly version in your assembly by adding the attributes like

C# [assembly: AssemblyVersion("1.0.0.0")] [assembly: AssemblyFileVersion("1.0.0.0")]

and the way you are calling Assembly class to get the version is correct. The example in the link https://msdn.microsoft.com/en-us/library/system.reflection.assembly(v=vs.110).aspx is demonstrating that

---

@weshaggard commented on Fri Apr 07 2017

.NET Core tooling is a little different because we have enabled folks to set the value in msbuild properties directly. @golfguy0082 have a look at https://github.com/dotnet/sdk/issues/2 which is I think the closest set of documentation that I can find on the matter.

---

@tarekgh commented on Fri Apr 07 2017

I'll move this issue to the SDK repo per Wes comment

[dasMulli]

@golfguy do you maybe build before publishing? There is an issue with incremental build when you specify version properties only from the command line https://github.com/dotnet/sdk/issues/967
You can check by deleting the obj directory and restoring + publishing again (or just delete obj/ + configuration - e.g. obj/Debug)

[golfguy0082]

Thank you all! Especially @weshaggard and @dasMulli! After some more investigation, it looks like I'm seeing the same issue that @dasMulli describes in #967 . It also sounds like the answer to my original question is "the 'officially recommended' way to version .net core assemblies (at least from msbuild's perspective) is still in-flux".

Perhaps my best bet right now is to simply omit the dotnet build from my build definition and simply skip straight to dotnet publish so that the project is only being built "once".

[weitzhandler]

How can I achieve auto increment of the assembly version like we could with AssemblyVersion("1.0.*") (which generates this compiler error in the new projects):

Error CS7034: The specified version string does not conform to the required format - major[.minor[.build[.revision]]]

Any ideas please?

[svick]

@weitzhandler Looking at the source code, wildcards are only allowed if the build is not deterministic, which seems to be the default for .Net Core projects.

Adding <Deterministic>False</Deterministic> to my csproj indeed fixes the issue for me.

Though the error message does not help with figuring that out, so I have opened an issue about that: https://github.com/dotnet/roslyn/issues/22660.

[livarcocc]

Given that the issues referenced here have all be addressed, I am going to close this one. If I got this wrong, please comment and we can re-activate it.

[oliverjanik]

This has been closed, but what is the answer to the original question?

[dasMulli]

@oliverjanik the original problem was an incremental build issue that has since been fixed in 2.0+ SDKs.
If you encounter a new issue or difficulties, do consider opening a new issue.