CODEWITHSUNDEEP
.netvisual-studiotfsmsbuild.net-core
Alexander Matusiak
Alexander Matusiak

Reputation: 1828

Package version is always 1.0.0 with dotnet pack

TLDR: Where is dotnet pack pulling the version information when it creates the nuget package for an assembly?

I have a library, that I had transitioned from a .NET 4.6.1 project to a .NET Core project with project.json. For my CI during this period (using TFS 2015 vnext), I would get my version number and replace the version number in the project.json file with the new version. The dotnet pack command would pick the version up just fine, and create a new package with the updated version number.

Last week, I upgraded from TFS 2015 to TFS 2017. Turns out, project.json was replaced with an updated .csproj file. I've updated my CI. During my CI - I update my /Properties/AssemblyInfo.cs file, replacing the AssemblyVersion tag with the version for the current build. Then I build the solution - which builds just fine. Then I package the solution.

However, despite the AssemblyVersion and AssemblyFileVersion being set in AssemblyInfo.cs to the correct build number - dotnet pack is still producing .nupkg files that are *.1.0.0.nupkg.

What am I missing?

Here is my pack command:

dotnet pack $projectFile -o $currentDirectory

Upvotes: 98

Views: 67338

Answers (5)

user29453730
user29453730

Reputation: 1

I had the same issue using Azure Devops pipeline (the DLL version from my pack was always 1.0.0 but the package was like 2.4.1)

The /p:VersionPrefix or /p:buildVersionPrefix doesn't work with pack (I think all properties are discarded).

I didn't tested the Command = custom" instead of "pack" but maybe /p: work using custom.

Here is what I finally did to fix the issue (You need to add the version in the buildProperties) :

Here is my step :

- task: DotNetCoreCLI@2
  displayName: 'Pack NuGet Package - ${{ parameters.buildConfiguration }}'
  condition: succeeded()
  inputs:
    command: 'pack'
    arguments: '--no-build --configuration ${{ parameters.buildConfiguration }} ${{ parameters.buildArguments }}'
    includeSymbols: true
    outputDir: '$(Build.ArtifactStagingDirectory)/${{ parameters.buildConfiguration }}'
    packagesToPack: '**/${{ parameters.buildMainProjectName }}.csproj'
    versioningScheme: 'byEnvVar'
    versionEnvVar: 'buildVersionPrefix'
    buildProperties: 'VersionPrefix=${{ parameters.buildVersionPrefix }};VersionSuffix=${{parameters.buildVersionSuffix }}'

So now I have my dll within the pack with the valid version.

Upvotes: 0

madhusai vemulamada
madhusai vemulamada

Reputation: 29

I've tried many variations of changing the version of the target nuget package and the following solution by my colleague worked for me. In the src folder, there is a file called 'Directory.Build.props' where the versions are set like below:

  <Target Name="CustomVersion" AfterTargets="MinVer">
    <PropertyGroup>
      <FileVersion>$(MinVerMajor).$(MinVerMinor).$(MinVerPatch)</FileVersion>
      <AssemblyVersion>$(MinVerMajor).$(MinVerMinor).$(MinVerPatch)</AssemblyVersion>
    </PropertyGroup>
  </Target>

You can replace this with version you are trying to create the nuget package eg:

  <Target Name="CustomVersion" AfterTargets="MinVer">
    <PropertyGroup>
      <FileVersion>106.11.7</FileVersion>
      <AssemblyVersion>106.11.7</AssemblyVersion>
      <InformationalVersion>106.11.7</InformationalVersion>
      <PackageVersion>106.11.7</PackageVersion>
    </PropertyGroup>
  </Target>

Now, on running 'dotnet pack -c Release -o nuget -p:IncludeSymbols=true -p:SymbolPackageFormat=snupkg' respective nuget package with desired version will be created

Upvotes: 2

Sudhanshu Mishra
Sudhanshu Mishra

Reputation: 6733

NOTE: I understand this question is not specifically about VSTS/Azure Dev Ops but a search for how to do this on a build pipeline lands here so adding what worked for me

  1. Use the dotnet core task
  2. Tools version 2.*
  3. Command = custom
  4. Custom Command = pack
  5. Arguments = -p:Version=1.0.$(Build.BuildId) -o $(Build.ArtifactStagingDirectory)

The -o argument is required if the task following the packaging is going to push to a feed (isn't that why one would build packages?)

Upvotes: 20

Edward
Edward

Reputation: 1507

Better yet, specify /p:Version=$(Build.BuildNumber) (TFS/VSTS) on the dotnet pack command and it will build it with the specified version in the nuget package. Example (non TFS specific): 

dotnet pack .\src\example\example.csproj -o c:\published\example -c Release /p:Version=1.2.3

Example (TFS specific) <- we use this for our TFS 2017 packing using a powershell script step.

dotnet pack $(Build.SourcesDirectory)\src\example\example.csproj -o $(Build.ArtifactStagingDirectory)\Pack -c Release /p:Version=$(Build.BuildNumber)

Note: It does not update package reference versions.

Upvotes: 124

Nate Barbettini
Nate Barbettini

Reputation: 53710

When you use dotnet pack, the version is pulled from the project definition (previously project.json, now *.csproj), not AssemblyInfo.cs. So, your new workflow will be very similar to what it was with project.json.

From the project.json to csproj migration docs, you can use the VersionPrefix and VersionSuffix properties.

Before:

{
  "version": "1.0.0-alpha-*"
}

Now:

<PropertyGroup>
  <VersionPrefix>1.0.0</VersionPrefix>
  <VersionSuffix>alpha</VersionSuffix>
</PropertyGroup>

You can also use the single Version property, but the docs warn that this "may override version settings during packaging".

<PropertyGroup>
  <Version>1.0.0-alpha</Version>
</PropertyGroup>

Upvotes: 61

Related Questions