AArnott on main
Update doc links Force non-shallow clones Fixes… Switch to using dotnet-coverage… and 6 more (compare)
AArnott on libtemplate
AArnott on libtemplate
Update doc links Force non-shallow clones Fixes… Switch to using dotnet-coverage… and 5 more (compare)
"inherit": trueand then set only what they want to override.
nbgv prepare-releaseonly updates one version.json file (the one you point it at), so if you have sub-level global.json files that set
"version": "1.2-preview"then they will remain in preview even while the root level one drops its
-previewsuffix to the verison, even when the parent version.json doesnt have that suffix in its version, i.e. because it has been removed after running
1.2-preview). Are you saying that
nbgv prepare-releaseis removing the
-previewsuffix even from the subfolder? (hint: you should be running that tool from the directory containing the root file, or specifying the path explicitly).
How to modify the generated version properties using some msbuild target? We are using the Nuget package, and don't have to do much, we just do these steps in our CI pipeline => VS Build => Nuget Push => Publish => Publish Build Artifacts
Do I need to modify the version properties in the pipeline or is it from our c# code somehow?
@nrpatil1993 No C# or pipeline changes should be required. It's an msbuild target, so you could for example add a
Directory.Build.targets file to the root of your repo with content like this:
<Project> <Target Name="TinkerWithVersionProperties" AfterTargets="GetBuildVersion"> <PropertyGroup> <NuGetPackageVersion>$(NuGetPackageVersion)-abc</NuGetPackageVersion> </PropertyGroup> </Target> </Project>
That would effectively forcibly add
-abc to the end of every nuget package. Now there are better ways to do that particular thing, but the point is you can take the msbuild properties that nb.gv sets and tailor them to your exact needs.
You can see the full list of properties that nb.gv sets in msbuild here.
Ok. Did the changes. Have added this file in the same folder where the .csproj exist.
<?xml version="1.0" encoding="utf-8"?> <Project> <Target Name="TinkerWithVersionProperties" AfterTargets="GetBuildVersionCore"> // or GetBuildVersion <PropertyGroup Condition="$(NuGetPackageVersion.EndsWith('$(GitCommitIdShort)'))"> <NuGetPackageVersion>$(MajorMinorVersion).$(GitVersionHeight)-pre$([System.DateTime]::UtcNow.ToString(yyyyMMddHHmmss))</NuGetPackageVersion> </PropertyGroup> </Target> <Target Name="AdjustVersion" AfterTargets="GetBuildVersionCore"> // or GetBuildVersion <PropertyGroup> <AssemblyInformationalVersion>$(NuGetPackageVersion)</AssemblyInformationalVersion> </PropertyGroup> </Target> </Project>
With this change, when I build the code locally, it is adding Product version with the required version. But when I push it and run the CI pipeline, it still goes with the regular version having git-commit Id in it, and it is not getting updated.
Am I doing anything incorrect here?
-blswitch to msbuild or
dotnet buildand collect the resulting msbuild.binlog file as an artifact. Then open that file using the tool at https://msbuildlog.com and see whether your target runs and what (else) happens to those properties that you're setting.
nerdbank.gitversioning\3.4.244\build\MSBuildCore\LibGit2Sharp.dll nerdbank.gitversioning\3.4.244\build\MSBuildCore\NerdBank.GitVersioning.dll nerdbank.gitversioning\3.4.244\build\MSBuildCore\Nerdbank.GitVersioning.Tasks.dll nerdbank.gitversioning\3.4.244\build\MSBuildCore\Newtonsoft.Json.dll nerdbank.gitversioning\3.4.244\build\MSBuildCore\Validation.dll
Is it a bug that NBGV uses the new version number from an uncommited version.json but ignores changes to the prerelease-tag?
In an uncommited version.json I can change the version number and nbgv get-version will print the new version directly, without commiting. Changes to the prerelease -tag are completely ignored until I commit the changes.
version.jsonfile that sets the version to
1.2.3-alphaand your stable branch set to
1.2.2(or whatever you most recent stable version was). When your 1.2.3 development branch becomes stable, you remove the
-alphasuffix from the
version.jsonfile for that branch. Does that help?
mainbranch where I'm developing 1.1-alpha, then I may want the
v1.0branch to periodically merge into
mainso that v1.1 will release with all the same fixes that v1.0 had. Nerdbank.GitVersioning works naturally with this because
mainwill have the most recent change to
version.jsonso a merge from
v1.0will not touch version.json, leaving both branches building the version they mean to.
1.2.3-alphabranch merges into a
1.2.3branch. What becomes of the source branch at that point? Does it remain
1.2.3-alphaor does it advance to
1.2.4? And was the target branch
1.2.3before and after the merge?
develop's merge to
mainthat the team of devs working in
developwould have to 'slow down' and not destabilize the branch. The way I and teams around me have done it is work never slows in the primary dev branch, and stabilization happens after branching off, which gives a fine opportunity to change the version.json file. In fact this is so common we have the
nbgv prepare-releasecommand which automates branching off for stabilization that automatically trims the
-prereleasetag on the servicing branch and advances the unstable version from 1.2.3 to 1.2.4 or whatever the policy is that you set in version.config.
develophave conflicting changes for version.json, your gitattributes file could allow git merge to work without conflicts and just leave the copy in the target branch alone.
AfterTargets="GetBuildVersion"attribute, you can review and edit any of the many msbuild properties that NB.GV sets. You could consider the active branch name (
BuildingRef) property and remove the -prerelease tag from the version when the branch being built is
GitVersionBaseDirectoryproperty (or environment variable) to specify where to look for the version.json file. So you could have two version files, in two different directories, and have a github action in your workflow set the
GitVersionBaseDirectoryenv var based on the branch being built to achieve what you want.
pathproperty is documented as a root below the config file, or do I misunderstand the usage and it could be a config file? I'm not using MSBuild, I'm using the github actions workflow and I'm using dotnet publish, see https://github.com/ptr727/PlexCleaner/blob/develop/.github/workflows/BuildPublishPipeline.yml
-prereleasetag, but not the minor version.
GetBuildVersion. A bunch of msbuild properties are set by that target and you can read them and rearrange them all you want.
nbgv get-versioncommands will no longer work for you.