Use GitInfo to generate the Version Info.

[dellis1972]

So lets' use the GitInfo NuGet
Package to generate the required version information for the assemblies
in this repo.
The base version is controlled from GitInfo.txt. This is where the
version should be edited.
The NuGet keeps track of the number of commits made since the GitInfo.txt
was changed. So unless there is a major version change
(or you run out of numbers) there should be no need to alter the version
on a regular basis.

All of the projects in the repo will then pick up the same version
information was we will set the MSBuild Version property as well as
the InformationalVersion. The latter will contain the git commit and
branch.

[akoeplinger]

should we use an explicit version rather than a floating version for GitInfo here?

[jonpryor]

Probably, yes.

[jonpryor]

@dellis1972 : while playing around with this, is there a reason to use/prefer a "3-tuple" for GitInfo.txt? I see that $(Version) is $(GitSemVerMajor).$(GitSemVerMinor).$(GitSemVerPatch), but $(GitSemVerPatch) appears to be $(GitBaseVersionPatch)+$(GitCommits), i.e. if $(GitBaseVersionPatch) is 0, as is the case in 1.0.0, then $(Version) is e.g. 1.0.1, as $(GitCommits) is >= 1.

This makes for slightly "head-scratching" behavior, as I wonder where this .1 came from…

Having GitInfo.txt instead contain 1.0 also works, while removing the "mental overhead" of trying to figure out how the (no longer existing) 3rd value relates to the generated $(GitsemVerPatch) value.

[jonpryor]

Should this use git-rev-head instead of git-head? git-rev-head is used by Mono.Android.dll: dotnet/android@b620689

<InformationalVersion>$(Version); git-rev-head:$(GitCommit); git-branch:$(GitBranch)</InformationalVersion>

[jonpryor]

Commit message for review:

[build] Use GitInfo to generate $(Version) (#131)

Context: http://github.com/xamarin/xamarin-android/commit/2d81740cc1c708cd0474c9eac8936cd7abfc72e3
Context: https://github.com/xamarin/xamarin-android/issues/5749

In order to better support building solutions which reference both
.NET 6 and legacy projects within Visual Studio, we have begun
strong-naming all the MSBuild-related assemblies; see also 87acd6b9.
This allows loading two different version of the "same" assembly, e.g.
`Microsoft.Android.Build.BaseTasks.dll`, from two different locations
within the same AppDomain/AssemblyLoadContext.

However, strong-naming is only part of the solution.  The other part
is that, for sanity and reliability, the "two different versions of
the 'same' assembly" should *also* have different assembly *versions*.
If they have the same assembly version, are they truly different?

Update the build system by adding a `Directory.Build.targets` and
`GitInfo.txt` file so that the the [`GitInfo`][0] [NuGet Package][1]
will be used to "fully" set the `$(Version)` MSBuild property,
consisting of the major and minor version numbers contained within
`GitInfo.txt`, along with a "computed" `$(GitSemVerPatch)` value
based on the "patch version" in `GitInfo.txt`, if present, added to
the number of commits which have occurred since `GitInfo.txt` changed.

Additionally, set the `$(InformationalVersion)` MSBuild property so
that it mirrors the behavior in [`Mono.Android.dll`][2]:

	[assembly: System.Reflection.AssemblyInformationalVersionAttribute("1.0.1; git-rev-head:4c2e36c; git-branch: main")

[0]: https://github.com/devlooped/GitInfo
[1]: https://www.nuget.org/packages/GitInfo/2.1.2
[2]: https://github.com/xamarin/xamarin-android/commit/b620689ddf0214b1e38d5feab9e2ea7a653614ff

[dellis1972]

@dellis1972 : while playing around with this, is there a reason to use/prefer a "3-tuple" for GitInfo.txt? I see that $(Version) is $(GitSemVerMajor).$(GitSemVerMinor).$(GitSemVerPatch), but $(GitSemVerPatch) appears to be $(GitBaseVersionPatch)+$(GitCommits), i.e. if $(GitBaseVersionPatch) is 0, as is the case in 1.0.0, then $(Version) is e.g. 1.0.1, as $(GitCommits) is >= 1.

This makes for slightly "head-scratching" behavior, as I wonder where this .1 came from…

Having GitInfo.txt instead contain 1.0 also works, while removing the "mental overhead" of trying to figure out how the (no longer existing) 3rd value relates to the generated $(GitsemVerPatch) value.

I used the 3 digit one because that is what was in the demo. I'll change it to 2 digit. I don't see any reason to keep it at 3 since the 3rd one is calculated.