Ensuring azure pipeline built dll and nuget package contain same info as csproj version

Question

I am reposting with a specific question as i have understand a powershell script is requried in addition to azure-pipelines.yml.

How would i achieve the same output/formatting using azure pipelines to provide the following versioning in an output file (and matching nuget package info per https://www.nuget.org/packages/MediatR/).

I understand this would be a powershell script, i have checked on MediatR and see https://github.com/jbogard/MediatR/blob/master/Build.ps1 but can't see how i would apply that to an azure pipeline step.

In summary the the verisn prefix should be used <VersionPrefix>1.0.1</VersionPrefix> (or whatever the version is) from my csproj, and applied to the file version property both in the binary dll and nuget package.

I would also like to set the product version of the dll to the specific build-datetime (or commit string as has been used in case of MediatR).

I am specifically looking for a script (powershell and associated yaml to link the scripted version strings) and associated steps, appreciate a big ask however I cannot find any concrete answers on google or Stackorerflow - a link to a tutorial would be perfect.

Pointers appreciated.

So what you want is something like: FileVersion,NugetPackageVersion=1.0.1.xxx and ProductVersion=1.0.1.builddatetime ? But what do you mean the specific build-datetime, you want to specify the build-datetime manually? I checked your csproj in another issue and maybe you should put the `VersionPrefix` as one property instead of metadata... — LoLance, Jan 20 '20 at 06:52

score 1 · Accepted Answer · answered Jan 20 '20 at 10:01

In summary the the verisn prefix should be used 1.0.1 (or whatever the version is) from my csproj, and applied to the file version property both in the binary dll and nuget package.

I would also like to set the product version of the dll to the specific build-datetime (or commit string as has been used in case of MediatR).

Apart from the PowerShell direction, we may consider msbuild property as another direction.

This is my test.csproj:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <!--Add other properties here.-->
  </PropertyGroup>

  <PropertyGroup> <!--Custom Property Group for CI/CD-->
    <MyVersionPrefix>1.0.1</MyVersionPrefix>
    <MyVersionSuffix>0</MyVersionSuffix>
    <BuildDateTime>0</BuildDateTime>
    <AssemblyVersion>$(MyVersionPrefix).$(MyVersionSuffix)</AssemblyVersion> <!--File Version-->
    <Version>$(MyVersionPrefix).$(BuildDateTime)</Version> <!--Product Version-->
    <PackageVersion>$(MyVersionPrefix).$(MyVersionSuffix)</PackageVersion> <!--Nuget Package Version-->
    <Copyright>Just for test.</Copyright>
  </PropertyGroup>
</Project>

I have one custom Property Group to define properties like File Version, Product Version and Package Version. Instead of using <VersionPrefix>1.0.1</VersionPrefix>, I use custom <MyVersionPrefix>1.0.1</MyVersionPrefix>.

This can work well to restore,build in local development. If you also need to pack the project locally, you can comment(using <---->) this Property Group.

To configure this project with CI/CD:

My opinion is to override the properties defined in xx.csproj. For me, I created one Suffix pipeline variable:

And then set the pipeline build number format to: $(date:yyyyMMdd)$(rev:r).

Then I specify the dotnet build task and dotnet pack task like this:

- task: DotNetCoreCLI@2
      displayName: "Build Solution"
      inputs:
        command: build
        projects: '**/*.csproj'
        arguments: '--configuration $(BuildConfiguration) -p:MyVersionSuffix=$(Suffix) -p:BuildDateTime=$(Build.BuildNumber)'

- task: DotNetCoreCLI@2
      displayName: 'dotnet pack'
      inputs:
        command: pack
        nobuild: true
        buildProperties: 'MyVersionSuffix=$(Suffix)'

In this way, I can pass value of $(Suffix) and $(Build.BuildNumber) from build pipeline to msbuild command. I can control the file version, product version, nuget package version by pipeline variables. (About the corresponding property of the file,product,package versions see my project file above.)

If set the Suffix variable 19, then after the build and package I can get a Nuget package whose package version is 1.0.1.19. In which the assembly has same file version 1.0.1.19 and product version like 1.0.1.202001208. If you don't want one increasing product version, you can then specify the value you want in build task with: -p:BuildDateTime=AnyValueYouWant.

Hope it helps and if I misunderstand anything, feel free to correct me :)

Thanks Lance for your time, much appreciated and this looks great. There are other ways i was told to do this by ignore anything in the actual project file itself, and control everyting from the pipeline vatiables (even major/minor etc)? Any reasons behind this for best practice etc rationale? This is my first pipeline setup so appreciate your help it helping me understand options and why this is better (it does seem to have more control than just a simple version) - any downsides to this (controlling via build pipeline as opposed to versions defined in source files) that I need to be aware? — morleyc, Jan 20 '20 at 16:07
@g18c Just my opinion, when we need to build and pack project multiple times in devops, it avoids some extra modifies to project file itself if we use pipeline variables to control the process. If we define versions in source files, we need to modify several parts(file,product,package version,), and we have to make sure the file version and package version have same value manually. Also you can choose to define them directly in csproj, for project that won't be built and packed many times one day, these two ways actually don't make big difference... — LoLance, Jan 21 '20 at 10:34

Ensuring azure pipeline built dll and nuget package contain same info as csproj version

1 Answers1