8

We have been using a Bamboo build server for a while now and we have GitVersion installed so it can be selected as a task in the Build plan. We typically use the /UpdateAssembleInfo argument when we run the task. For .NET Framework projects, this would update the assemblyinfo file in the source with the bamboo versioning settings so the .NET assemblies had the same version info as our Bamboo builds and subsequent Bamboo deployment, allowing us to know the version of the deployed project in the field by examining the assembly file properties. This was all working quite well.

However, we are now building and deploying .NET Core 2.0 solutions and are finding that GitVersion /UpdateAssemblyInfo is not working.

I searched for a fix for .NET Core but was only able to find solutions that involved using the project.json file, which is no longer used with .NET Core 2.0 ( it changed to the *.csproj file).

I looked at http://gitversion.readthedocs.io/en/latest/usage/command-line/ and I tried running

gitversion.exe /UpdateAssemblyInfo MyProjectName.AssemblyInfo.cs /EnsureAssemblyInfo 

where MyProjectName represents the actual project name suffix for the assemblyinfo.cs file in the .NET Core 2.0 ..\\obj\release\netcoreapp2.0 folder. But it did not update that file.

I have to assume that there has to be a solution for using GitVersion with Bamboo and.NET Core 2.0 but I am having a hard time finding one.

Any ideas?

reckface
  • 5,678
  • 4
  • 36
  • 62
whiskytangofoxtrot
  • 927
  • 1
  • 13
  • 41

2 Answers2

4

The latest version of GitVersion provides /updateprojectfiles switch to update version info in the Sdk-style .csproj/.vbproj/.fsproj recursively.

From GitVersion/Usage/CommandLine/Arguments:

/updateprojectfiles
    Will recursively search for all project files
    (.csproj/.vbproj/.fsproj) files in the git repo and update them
    Note: This is only compatible with the newer Sdk projects

It produces the needed attributes even if they are not present in the project files, resulting in following properties:

<Project>
    <PropertyGroup>
        <AssemblyVersion>1.0.0.0</AssemblyVersion>
        <FileVersion>1.0.0.0</FileVersion>
        <InformationalVersion>1.0.0-versionNumber.N+Branch.branchName.Sha.commitId</InformationalVersion>
        <Version>1.0.0-versionNumberNNNN</Version>
   </PropertyGroup>
alex.z
  • 84
  • 7
3

As a workaround, you may consider specifying the assembly info as project properties in .csproj

<PropertyGroup>
    <Version>1.2.3.4</Version>
    <AssemblyVersion>2.0.0.0</AssemblyVersion>
    ...
</PropertyGroup>

and then setting values during dotnet build. In addition to its options, the dotnet build command accepts MSBuild options like /property

/property:name=value
/p:name=value
Set or override the specified project-level properties, where name is the property name and value is the property value. Specify each property separately, or use a semicolon or comma to separate multiple properties.

So your build command will be something like

dotnet build /p:Version=1.2.3.4;AssemblyVersion=1.2.3.4
Set
  • 47,577
  • 22
  • 132
  • 150
  • This worked for setting the assembly version during the build. And on my Bamboo build server, I can substitute the ${bamboo.BuildNumber} variable for the last value in the version sequence, i.e. AssemblyVersion=1.2.3.${bamboo.BuildNumber}. Thanks, – whiskytangofoxtrot Apr 26 '18 at 11:49
  • 1
    I got to use these arguments in `dotnet publish` with AzDO Pipeline, because `build` step just build projects in the solution and `publish` actually generates artifacts – Mihir Dec 27 '18 at 09:43