You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/msbuild.md
+75Lines changed: 75 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,6 +2,23 @@
2
2
3
3
Installing the `Nerdbank.GitVersioning` package from NuGet into your MSBuild-based projects is the recommended way to add version information to your MSBuild project outputs including assemblies, native dll's, and packages.
4
4
5
+
If you want the package to affect all the projects in your repo, and you use `PackageReference` (rather than `packages.config`),
6
+
you can add this to a repo-level `Directory.Build.props` file:
7
+
8
+
```xml
9
+
<ItemGroup>
10
+
<PackageReferenceInclude="Nerdbank.GitVersioning"
11
+
Version="(latest-version-here)"
12
+
PrivateAssets="all"
13
+
Condition="!Exists('packages.config')" />
14
+
</ItemGroup>
15
+
```
16
+
17
+
The condition prevents the `PackageReference` from impacting any `packages.config`-based projects
18
+
such as vcxproj that may be in your repo.
19
+
Such projects will require individual installation of the Nerdbank.GitVersioning nuget package
20
+
using the NuGet Package Manager in Visual Studio.
21
+
5
22
## Public releases
6
23
7
24
By default, each build of a Nuget package will include the git commit ID.
@@ -21,6 +38,64 @@ You should only build with this property set from one release branch per
21
38
major.minor version to avoid the risk of producing multiple unique NuGet
22
39
packages with a colliding version spec.
23
40
41
+
## Custom build authoring
42
+
43
+
If you are writing your own MSBuild targets or properties and need to consume version information,
44
+
Nerdbank.GitVersioning is there to help.
45
+
The version information created by this package is expressed as MSBuild properties.
46
+
These properties are set by the `GetBuildVersion` target defined in this package.
47
+
This means any dependency you have on these properties must ensure this target has already executed.
48
+
This can be done by defining your own msbuild target like so:
<MyOwnProperty>My assembly version is: $(AssemblyVersion)</MyOwnProperty>
54
+
</PropertyGroup>
55
+
</Target>
56
+
```
57
+
58
+
In the above example, the `AssemblyVersion` property, which is set by the
59
+
`GetBuildVersion` target defined by Nerdbank.GitVersioning, is used to define
60
+
another property.
61
+
It could also be used to define msbuild items or anything else you want.
62
+
63
+
### MSBuild properties defined in `GetBuildVersion`
64
+
65
+
Many MSBuild properties are set by `GetBuildVersion` allowing you to define or redefine
66
+
properties in virtually any format you like.
67
+
The authoritative list is [here](https://github.com/dotnet/Nerdbank.GitVersioning/blob/dae20a6d15f04d8161fd092c36fdf1f57c021ba1/src/Nerdbank.GitVersioning.Tasks/GetBuildVersion.cs#L300-L323) (switch to the default branch to see the current set).
68
+
69
+
Below is a snapshot of the properties with example values.
70
+
Note that the values and formats can vary depending on your `version.json` settings and version height.
Repos with many projects or many commits between major/minor version bumps can suffer from compromised build performance due to the MSBuild task that computes the version information for each project.
0 commit comments