Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: How to version dotnet core assemblies #1098

tarekgh opened this issue Apr 7, 2017 · 7 comments

Question: How to version dotnet core assemblies #1098

tarekgh opened this issue Apr 7, 2017 · 7 comments


Copy link

@tarekgh tarekgh commented Apr 7, 2017

@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:
ReflectionUtils is an arbitrary type in my assembly. No matter what I try, the version retrieved from the above line shows

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

[assembly: AssemblyVersion("")]
[assembly: AssemblyFileVersion("")]

and the way you are calling Assembly class to get the version is correct. The example in the link 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 #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

Copy link

@dasMulli dasMulli commented Apr 7, 2017

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

Copy link

@golfguy0082 golfguy0082 commented Apr 7, 2017

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".

Copy link

@weitzhandler weitzhandler commented Oct 10, 2017

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?

Copy link

@svick svick commented Oct 11, 2017

@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: dotnet/roslyn#22660.

Copy link

@livarcocc livarcocc commented Feb 9, 2018

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.

Copy link

@oliverjanik oliverjanik commented Aug 31, 2018

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

Copy link

@dasMulli dasMulli commented Aug 31, 2018

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

7 participants