My team has git repositories which house multiple related .NET class library projects grouped in a single solution. Essentially, they are like small mono-repos specific to a particular domain of libraries. Each class library project could be updated and versioned independently. So, there could be one class library on Version 1.0.1 and another on version 2.1.0, and so on.
When building in Azure DevOps Pipelines, I am easily able to build all of the packages at once, however, the version number for each of the packages is the same and I haven't been able to get the build or pack commands to reference the version number in the .csproj files.
When I read this article, it doesn't seem to indicate a way to do it, but when I run the build or pack commands on my local machine it uses the value found in the .csproj file like I want it to.
<PackageVersion>1.0.1</PackageVersion> generates a nuget with the correct versioning info.
How can I get the Azure DevOps Pipeline build/pack commands to respect the version that is defined in the .csproj file?
After some trial and error, it appears that I was able to resolve this issue by using a <Version>1.0.1</Version> property defined in the .csproj file, rather than <PackageVersion>1.0.1</PackageVersion> which my team had been using since before I came on board.
By request, here is the currently functioning YAML for the build stage:
- task: DotNetCoreCLI@2
displayName: Build
inputs:
command: 'build'
projects: |
**/*.csproj
!**/*Test.csproj
!**/*Tests.csproj
configuration: 'Release'
arguments: '-o "$(Build.ArtifactStagingDirectory)"'
The above YAML ignores test projects and specifies a custom output directory which is referenced later in the pipeline.