devlooped / gitinfo Goto Github PK

Installing GitInfo in a WPF app causes the build to fail, with the error message that ThisAssembly.GitInfo.g.cs was specified more than once in the Sources parameter to the Csc task.

Running using the MSBuild Structured Log Viewer confirms that the value is indeed in there twice! What appears to be happening is that the project generated by MSBuild for compilation of the solution already has the file (because it's been added to the outer compilation), but then the target is re-run and the file is added again to the inner compilation.

You can see this in the attached build log (using Structured Log Viewer's binary format)--I'm using version 1.1.66, installed from NuGet about...30 minutes ago. The project is open source--the branch to look at is https://github.com/bojanrajkovic/Reedy/tree/gitinfo.

Reedy Broken Build.zip

What is the proper way of declaring a ThisAssemblyNamespace variable so that ThisAssembly is declared within a namespace?

Hi,

I want to use a release SemVer formats when the build is on the build system and in a release branch and a pre-release format in all other cases. How can I do this?

The formats I want are:

<Major>.<Minor>.<Path>+<meta>
<Major>.<Minor>.<Path>-Beta+<meta>

I can determine if a release msbuild csproj by checking branch name and an environent variable the build system sets. How can I apply this to the generated AssemblyInfo informational version.

We have noticed issue that on TeamCity build server, when a git verson control source is checked out. It would run pack-refs --all before start the build. That cleared out all the files under .git/refs/heads and store them in the .git/packed-refs file. Then GitInfo wouldn't regenerate ThisAssembly when the branch head changes on build server unless it is a completely clean build. I think we should track the .git/packed-refs file too.

Since you're explicitly adding GitInfo to the project, running $(GitExe) --version should never fail.

I found a issue with a Solution with two projects using gitinfo.
They would fail on the String replace of the GitIsDirty while using the Git Cache file.
I suspect this is because the Variable GitIsDirty is not saved inside the gitcache text file and when applying the string substitution of the assembly file it would not replace it since it didn't find it.

I had to workaround it by always using GitSkipCache

GitInfo uses the command "git merge-base" to detect fork points. However this seems to not work whenever the "base-branch" is already ahead. Consequently the commit count does not work correctly.

Very oddly it seems to work whenever you had the expected commit checked out previously – what made it very tricky to detect this problem.

Example:

• Clone “https://github.com/jekelhart/GitInfoTry”
• Switch to branch “v1.0.0”
• git merge-base --fork-point “master”
  • or: git merge-base --fork-point “origin/master”
• expected result: fork point “fbb1db34c6317a6e8b319c1ec261e97ca1672c22” but result is empty

In the repo where we created this example tree in the first place the command returned the expected fork point. If you clone it new and fresh it does not return any result anymore.

Works, however, on branch “v2.0.0”. Assumption: because “master” is older.(?)

BR, Jakob

Could you make available the info on the project target. Ex: ThisAssembly.Compile.Target. Is that possible?

Thanks!

I noticed that GitInfo supports 3 different ways of getting the base commit position.

1. The last commit GitInfo.txt has changed.
2. If GitInfo.txt doesn't exist, the last commit current branch fork from GitDefaultBranch or GitCommit.
3. If no valid fork point could be found, the last tag from the current branch or GitBaseTag.

We are using workflow that we work on master branch and only branch close to the release date. I'm thinking about what would be the best way to use GitInfo.

We want to rely on the version from GitInfo.txt. Then that means we have to have the file from the start of the master branch and update it after each branch has been created. Is there a way to specify which commit as the base commit, like the GitDefaultCommit, but not editing csproj files. We have lots of projects so changing the files after each branch is not ideal. Can it be read from a file like GitInfo.txt?

Hi,

Resharper raises errors "Cannot access internal class 'ThisAssembly' here" for each reference to ThisAssembly in the AssemblyInfoExt.cs file. The project does compile and run so it evidently does work.

I toss up as to if this is a Resharper issue or something GitInfo can fix. Anybody else seeing this?

It appears right now GitInfo make some assumptions about the language of the project for assembly inspection. It would be nice if this was factored out and at least the straight git integration could work by default regardless of language. As is, $(GitThisAssembly) needs manually turned on which is a bit unfortunate.

When you run git describe --dirty you get an additional "-dirty" string added if there are uncommitted changes to the repository. I think it would be useful to have access to this state, perhaps just as a boolean.

If you are interested, I believe git diff-index --quiet HEAD will check this, returning 0 if clean and 1 if dirty.

I have a git repository with multiple VS projects that should change version independently.
Would it be possible to configure GitInfo to use tags with a certain prefix per project ?

Example:

• root
  • ProjectA\ProjectA.csproj
    Should use git tags with prefix a- (like a-1.1.0)
  • ProjectB\ProjectB.csproj
    Should use git tags with prefix b- (like b-1.2.0)

Any reason why this is still in pre-release?
I want to use it, but you're making me nervous 😉

GitInfo is correctly versioning our assemblies but I would like to extend this to versioning our nuget packages. The following is a snippet from our .csproj :

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp1.1</TargetFramework>
    <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
    <GeneratePackageOnBuild>True</GeneratePackageOnBuild>
    <PackageVersion>$(GitSemVerMajor).$(GitSemVerMinor).$(GitSemVerPatch)$(GitSemVerDashLabel)</PackageVersion>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="..\..\GlobalAssemblyInfo.cs" Link="Properties\AssemblyInfo.cs" />
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="gitinfo" Version="1.1.66" />
  </ItemGroup>
</Project>

Note the GeneratePackageOnBuild.

What do I have to do to generate those environment variables, $(GitSemVerMajor), etc. when I call dotnet build?

I can't debug my apps on Xamarin Live player as soon as I add GitInfo to the project.

The error I have :

Running /Users/me/Projects/TestGitInfo/Droid/bin/Debug/TestGitInfo.Droid.dll…
Start TestGitInfo.Droid, LGE LG-H870 Player, .
Attempting connection to debug address: 192.168.1.31:37847.
Connected to: 192.168.1.31:37847.
Deploying /Users/me/Projects/TestGitInfo/Droid/TestGitInfo.Droid.csproj…
Got device info: LGE LG-H870 Player (Android) @ 192.168.1.31:37847
Synchronizing files…
Building and running…
Built with 2 messages.
/Users/me/Projects/TestGitInfo/TestGitInfo/TestGitInfoPage.xaml.cs(1,1): error: 'ThisAssembly' is inaccessible due to its protection level
(1,1): error: Dependent project TestGitInfo.csproj failed to build, using old version.

To reproduce, I just created a blank new Xamarin Forms Project (PCL). Tested it worked with Live Player. OK.

Then I added GitInfo nuget and displayed ThisAssembly.Git.Commit in the Label that initialy displayed "Welcome to Xamarin Forms!".

As soon as we call ThisAssembly, we can't compile the project for Xamarin Live Player.

Any Idea ?

Hi, BC30209 Option Strict On requires all variable declarations to have an 'As' clause. is causing build to fail.

Any help would be appreciated, Thanks

If I make a git tag called "v1.0.1" and make a build, Git.SemVer.Patch is 1 and Git.Commits is 0. If I then make a commit and rebuild, Git.SemVer.Patch increases to 2 and Git.Commits increases to 1. What is the point of Git.SemVer.Patch automatically increasing with each commit if Git.Commits also does this? Doesn't this make the latter rather pointless and/or the former rather annoying?

I was hoping to have something like AssemblyFileVersion being Major.Minor.Patch and AssemblyInformationalVersion being Major.Minor.Patch.Commits, but that doesn't work with the current way Git.SemVer.Patch is calculated.

Would be interested to hear the author's thoughts on this. I have a feeling this is a git thing that can't be changed but maybe there's a workaround I haven't thought of.

EDIT: Never mind, I see that Git.BaseVersion.Patch can be used instead!

If you have a branch name of ermau/feature, GitInfo will read the branch name as feature only.

$ git name-rev --name-only HEAD
ermau/feature

I'm getting errors when writing version info into my logs, debugging shows the error:

error CS0433: The type 'ThisAssembly' exists in both 'MyProduct.MyProj, Version=0.1.0.0, Culture=neutral, PublicKeyToken=null' and 'Microsoft.Build.Utilities.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

I'm using VS2017.

At first I'd added it to all my projects in the solution but it didn't like the fact I had it in dependent projects, so I removed and have started trying to add just one by one, I've not managed the first one yet :) so I think I'm missing something obvious...

Missing quotes in GitInfo.targets line 370.
$(GitExe) rev-list --count "$(_GitLastBump)"..HEAD $([System.IO.Path]::GetDirectoryName("$(GitVersionFile)"))
should be
$(GitExe) rev-list --count "$(_GitLastBump)"..HEAD "$([System.IO.Path]::GetDirectoryName("$(GitVersionFile)"))"

Caused this error:
C:\Program Files (x86)\Jenkins\workspace\develop\packages\GitInfo.1.1.31\build\GitInfo.targets(370,3): warning MSB3073: The command ""C:\Program Files\Git\bin\git.exe" rev-list --count "65923a7"..HEAD C:\Program Files (x86)\Jenkins\workspace\develop" exited with code 128. [C:\Program Files (x86)\Jenkins\workspace\develop\project.csproj]
The previous error was converted to a warning because the task was called with ContinueOnError=true.
Build continuing because "ContinueOnError" on the task "Exec" is set to "true".
C:\Program Files (x86)\Jenkins\workspace\develop\packages\GitInfo.1.1.31\build\GitInfo.targets(586,4): error MSB4186: Invalid static method invocation syntax: "[MSBuild]::Add('$(GitBaseVersionPatch)', '$(GitCommits)')". Input string was not in a correct format. Static method invocation should be of the form: $([FullTypeName]::Method()), e.g. $([System.IO.Path]::Combine(a, b)). [C:\Program Files (x86)\Jenkins\workspace\develop\project.csproj]

It worked after adding the quotes manually -.-

For one project I work on, the customer wants to include the year and month in the AssemblyInformationalVersion ...

If I send you a pull request with a DateTimeOffsetUtc class (or just DateTime or DateTimeUtc) added next to Git in ThisAssembly, and the relevant replace strings in the msbuild task... will you take that?

e.g.:

public partial class DateTimeOffsetUtc
{
    Year         = "2015"
    Month        = "12"
    Day          = "16"
    DayOfWeek    = "Wednesday"
    DayOfYear    = "350"
    Hour         = "20"
    Minute       = "5"
    Second       = "55"
    Millisecond  = "261"
    Ticks        = "635858931552618551"
    Time         = "20:05:55"
    Date         = "2015-12-16"
}

I'm totally confused. I have a gitinfo.txt file within top-level of my repo.
No matter what i put into the file the ThisAssembly.Git.BaseVersion.Minor, ThisAssembly.Git.BaseVersion.Major, ThisAssembly.Git.BaseVersion.Patch keep the same.
Where does the definition of these variables come from?

The content of gitinfo.txt looks like this:
0.5.1

When I have the git.exe in the PATH, it should take the precedence over other search paths.

Commit 3ff0168 has broken my project, which does use XAML (a WPF project). Prior to this change it was building fine. After this change I get the following build error when using VS 2015 update 3:

obj\Debug\ThisAssembly.GitInfo.g.cs" was specified more than once in the "Sources" parameter

Excellent work, kzu. Nice and simple, versus other complex and black-box like solutions. Brilliant (like a Moq :) )...

Can you use this nuget package for managed c++? If not could you extend it ?

Regards

Hi,

First of all, great idea for a NuGet package. Wish I'd found it sooner.

Unfortunately, in trying to use ThisAssembly directly as per the readme.txt, i.e. I added this to my C# source:

[assembly: AssemblyVersion (ThisAssembly.Git.SemVer.Major + "." + ThisAssembly.Git.SemVer.Minor + "." + ThisAssembly.Git.SemVer.Patch)]
[assembly: AssemblyInformationalVersion (
  ThisAssembly.Git.SemVer.Major + "." +
  ThisAssembly.Git.SemVer.Minor + "." +
  ThisAssembly.Git.SemVer.Patch + "-" +
  ThisAssembly.Git.Branch + "+" +
  ThisAssembly.Git.Commit)]

I get this error:

ThisAssembly' is inaccessible due to its protection level

since it's declared as

  /// <summary>Provides access to the current assembly information.</summary>
  partial class ThisAssembly
  {

hence private.

Should ThisAssembly not be public in order to use as advertised?

Observed in both VisualStudio 2013, and VisualStudio for Mac 7.5.2.

Thanks

Since the actual commands being executed can easily be seen by running a detailed build and inspecting the Command property on the Exec task, there's no need to render all those git commands every time we run them.

Can someone please share a working .csproj example?
Or tell me wrong what is wrong with mine:

<Project Sdk="Microsoft.NET.Sdk" DefaultTargets="GitVersion">
  <PropertyGroup>
    <TargetFrameworks>netstandard1.0;net40</TargetFrameworks>
    <GeneratePackageOnBuild>true</GeneratePackageOnBuild>
    <version>$(GitTag)</version>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="GitInfo" Version="2.0.8" PrivateAssets="all" />
  </ItemGroup>
</Project>

Thanks!

First off, this library has been very helpful in getting our team up and running with package versioning. Thank you!

We have a single .sln with two (2) .NET Standard 2.0 class libraries. Both reference GitInfo 2.0.15. Placing a GitInfo.txt file in the repo root works as expected. Example, if that file includes the text "1.2.0", and there are 4 commits, we get the Sample.Library.1.2.4, and Another.Library.1.2.4.

The problem comes when we try to have independent version numbers per project, via individual GitInfo.txt file per project (as mentioned here):

• GitInfo.txt for Sample.Library contents: "3.1.0"
• GitInfo.txt for Another.Library contents: "2.7.0"

No matter how many times we commit, the "patch" number (which is based on $(GitSemVerPatch)) stays at "0". For example, we expect something like "Sample.Library.3.1.4.nupkg", but get "Sample.Library.3.1.0.nupkg".

Sample.Library.csproj:

<Project Sdk="Microsoft.NET.Sdk" InitialTargets="SetVersion">

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <IncludeSymbols Condition=" '$(Configuration)' == 'Debug' ">true</IncludeSymbols>
    <GeneratePackageOnBuild>true</GeneratePackageOnBuild>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="GitInfo" Version="2.0.15">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
    </PackageReference>
  </ItemGroup>

  <!-- Generate semantic versioning for packages -->
  <Target Name="SetVersion" BeforeTargets="Build;GetPackageVersion;_IntrospectProjectProperties" DependsOnTargets="GitInfo" Condition="'$(ExcludeRestorePackageImports)' != 'true'">
    <PropertyGroup>
      <!-- Packages for feature branches are marked as "alpha" (ex., 2.1.0-alpha426e8bcf) -->
      <GitSemVerDashLabel Condition="$(GitBranch.Contains('features'))">alpha$(GitCommit)</GitSemVerDashLabel>

      <!-- Packages for release branches are marked as "rc", release candidates (ex., 2.1.0-rc426e8bcf) -->
      <GitSemVerDashLabel Condition="$(GitBranch.Contains('releases'))">rc$(GitCommit)</GitSemVerDashLabel>

      <!-- Packages for the master branch have no suffix (ex., 2.1.0) -->
      <GitSemVerDashLabel Condition="$(GitBranch.Contains('master'))"></GitSemVerDashLabel>

      <PackageVersion Condition="'$(GitSemVerDashLabel)' != ''">$(GitSemVerMajor).$(GitSemVerMinor).$(GitSemVerPatch)-$(GitSemVerDashLabel)</PackageVersion>
      <PackageVersion Condition="'$(GitSemVerDashLabel)' == ''">$(GitSemVerMajor).$(GitSemVerMinor).$(GitSemVerPatch)</PackageVersion>
      <InformationalVersion>$(PackageVersion)</InformationalVersion>
    </PropertyGroup>
  </Target>

</Project>

Any insight into what I'm missing here would be helpful.

Please find attached a VS2015 example as a simple reproducible
GitInfoAnnotatedTag.zip

This has a C# console application, and depends on the GitInfo package (v2.0.11). There is a git repo for the project, with 3 commits on it, and start in the master branch.
Build and run the application. The console/debug output should be

Git branch is 'master'

Now, in a git bash console (or similar), make an annotated tag, e.g.

git tag -a hello -m world

and checkout to the tag

git checkout hello

Rebuild the application, and run again. The output is

Git branch is 'tags/hello^0'

The trailing ^0 only seems to appear for annotated tags.

ThisAssembly.Git.Tag is currently in the following form, e.g.:

public const string Tag = "v1.2.3-beta4-5-g6789abcd";

However, SemVer states that build metadata should be added via a plus sign, so this would be correct

public const string Tag = "v1.2.3-beta4-5+g6789abcd";

I'm not sure if this field is actually be specified to be a semantic version. So should this be changed or is this intended?

Could you set a default value for the property GitIsDirty in GitInfo.targets?

All other properties have default values, e.g. master for the branch, 0.1.0 for default version.

My problem is: If I build my project in a non-git setting (e.g. an exported version), the generated ThisAssembly.g.cs says
public const bool IsDirty = $GitIsDirty$;
and the build fails.

(Fot the time being, I set <GitIsDirty>1</GitIsDirty> in my project file. I'm not sure if this is the preferred solution).

I recently added a new tag v1.1.0 to my most recent git commit but for some reason EXEs I build are still using version information from the previous tag, v1.0.2. The SHA is being picked up properly but it seems to just ignore the new tag and assume the current commit is the 35th since the last tag. I use this version numbering:

<Assembly: AssemblyVersion(ThisAssembly.Git.SemVer.Major + "." + ThisAssembly.Git.SemVer.Minor + "." + ThisAssembly.Git.BaseVersion.Patch)>
<Assembly: AssemblyFileVersion(ThisAssembly.Git.SemVer.Major + "." + ThisAssembly.Git.SemVer.Minor + "." + ThisAssembly.Git.BaseVersion.Patch)>
<Assembly: AssemblyInformationalVersion(
    ThisAssembly.Git.SemVer.Major + "." +
    ThisAssembly.Git.SemVer.Minor + "." +
    ThisAssembly.Git.BaseVersion.Patch + "." +
    ThisAssembly.Git.Commits + "-" +
    ThisAssembly.Git.Commit)>

I've attached verbose build logs, where it does seem to find the new v1.1.0 tag, yet the builds are labelled v1.0.2.35-3998....

MyProjectOutput.zip

Any ideas? Am I doing something stupid?

I replaced SemanticGit with GitInfo in my project since the former was marked as obsolete. However, when I build my project, which resides on an SMB share, it just produces an error:

The expression "[System.IO.File]::ReadAllText(Z:\VB Projects\Music Folder Syncer\Project.git\HEAD)" cannot be evaluated. Could not find a part of the path 'Z:\VB Projects\Music Folder Syncer\Project.git\HEAD'.

Is this a bug or misconfiguration on my part? SemanticGit worked fine.

When using dotnet publish to build a .Net Core library (.Net Standard 1.3) while GitInfo is referenced, the build will fail due to attempting to download MSBuild via nuget, which exits with code 1.

It appears somewhere in the command nuget install MSBuild -outputdirectory "%user%\.nuget\packages\gitinfo\1.1.62\build\..\..\" -excludeversion -source "https://www.nuget.com/api/v2" there is something wrong that causes a "Illegal characters in path." problem.

If i had to guess whats going on, it would be that you've accidentally escaped a quote on Line 32 of GitInfo.xbuild but then that brings the question of, why does it resort to trying to use the xbuild target (Presumably Due to '$(MSBuildRuntimeVersion)' == '') when using the dotnet cli to publish a project?

I had a quick test of trying to remove the final \ to unescape the quote and the build went forward to using mono... Which isn't installed since i'm on a Windows system.

Hi,

I am not greatly familiar with msbuild and TFS, I am trying to use GitInfo semver variables when tagging my builds/releases in TFS. But they're not being resolved. Build runs successfully, just name tagging doesn't work correctly.

Do I need to expose $(GitSemVerMajor) etc as my own variables in .csproj?

Any help would be appreciated!

I have a solution and last hotfix is 2.119.16. GitInfo thinks that current version is 2.119.14. Where is tag and merge commint for hotfix/2.119.16. How can I find a reason of this calculation mistake?

To be precise, it's this line when the GitThisAssemblyMetadata property is true.

I'm not sure, but i believe there will be a similar, if not the same problem over in the VB .pp file as well

I installed v1.1.20 of the package on Desktop, Android, and iOS projects successfully, but for some reason it does not work on UWP.

Hi, it would be great if some kind of addin, helper or eg to use with Cake.

Thanks

Hi,
It would be great if there would be single Property to access preferred version scheme. Following was copied from your article

private const string VERSION = ThisAssembly.Git.SemVer.Major + "." + ThisAssembly.Git.SemVer.Minor + "." + ThisAssembly.Git.Commits + "-" + ThisAssembly.Git.Branch + "+" + ThisAssembly.Git.Commit;

So, it would be great if this combine information is available in single property.

Thanks

Works excellent! But:
Is it possible, to add some kind of 'CheckinDate' to the available "ThisAssembly.Git" constants? I would like to do something like this:
[assembly: AssemblyInformationalVersion(ThisAssembly.Git.CheckinDate + "-" + ThisAssembly.Git.Branch + "-" + ThisAssembly.Git.Commit)]

Will look like: 25.05.2018-/remote/main/-#3baxfwkjfa

Hi. I have been searching for a library to use the git info in my programs and I this one is the best I've found :)
I created a wpf application, installed this library from Nuget, made some commits and print the git info like this:

#if DEBUG
	Version = ThisAssembly.Git.SemVer.Major + "." +
		ThisAssembly.Git.SemVer.Minor + "." +
		ThisAssembly.Git.Commits + "-" +
		ThisAssembly.Git.Branch + "+" +
		ThisAssembly.Git.Commit + ".Debug" +
		".commits_" +ThisAssembly.Git.Commits;
#else
	Version = ThisAssembly.Git.SemVer.Major + "." +
		ThisAssembly.Git.SemVer.Minor + "." +
		ThisAssembly.Git.Commits + "-" +
		ThisAssembly.Git.Branch + "+" +
		ThisAssembly.Git.Commit + ".Release" +
		".commits_" +ThisAssembly.Git.Commits;
#endif

It works perfectly, but when I keep making commits and even changing to new branches the ThisAssembly.Git.Commits remains as '0'. (If I make tags 'Tag' and 'BaseTag' change, but the commit counter remains as '0').

• How can I make that counter (or the numbers of the BaseVersion or SemVer: Major , Minor and Patch) to increase automatically every time i make a new commit? (I read your documents but I didn't understand the customization part. I think it's related to adding a with a property in the .csproj of the project?. Can you please show me that with examples?).
• Is the example above using the correct way to print if a program is compiled as Debug or Release using your library?

Thanks in advance,

It would be nice to access it as dotnet tool:

dotnet gitinfo [options]

Error on OSX

/Users/rmarinho/.nuget/packages/gitinfo/2.0.8/build/GitInfo.targets(4,4): Error MSB4186: Invalid static method invocation syntax: "[MSBuild]::Add('$(GitBaseVersionPatch)', '$(GitCommits)')". Method '[MSBuild]::Add' not found. Static method invocation should be of the form: $([FullTypeName]::Method()), e.g. $([System.IO.Path]::Combine(`a`, `b`)).  (MSB4186) (TriggerVSTS)

Line 742 of GitInfo.targets

On projects with analyzers enabled - the analyzers will/could fail on the generated code.

If the generated code is marked with a <auto-generated /> comment as the first line, the file will be ignored by the analyzer.

obj\Debug\netcoreapp1.1\ThisAssembly.GitInfo.g.cs(29,17,29,29): error SA1205: Partial elements must declare an access modifier
obj\Debug\netcoreapp1.1\ThisAssembly.GitInfo.g.cs(28,3,28,5): error SA1515: Single-line comment must be preceded by blank line

Hi,
Recent build of GitInfo is broken, getting error

"C:\gitlab\builds\70fbc2c0\0\SequelMed\SequelMedServerSide\SequelMed\SequelMed.vbproj" (Build target) (1) ->
(_GitRoot target) -> 
  C:\gitlab\builds\70fbc2c0\0\SequelMed\SequelMedServerSide\packages\GitInfo\build\GitInfo.targets(185,4): error MSB4186: Invalid static method invocation syntax: "[MSBuild]::NormalizeDirectory($(_GitOutput.Trim()))". Method '[MSBuild]::NormalizeDirectory' not found. Static method invocation should be of the form: $([FullTypeName]::Method()), e.g. $([System.IO.Path]::Combine(`a`, `b`)).  [C:\gitlab\builds\70fbc2c0\0\SequelMed\SequelMedServerSide\SequelMed\SequelMed.vbproj]

    0 Warning(s)
    1 Error(s)

MSBuild: C:\Program Files (x86)\MSBuild\14.0

Getting my feet wet with this package, and I'm confused about where things are coming from. I have a project that looks like this:

When I build this with no GitInfo.txt and no customization, I get:

GitBranch=master;
GitCommit=8860bcb;
GitSha=8860bcb59f1e83db93e6aea90d1e8928bb1e692f;
GitBaseVersion=0.1.0;
GitBaseVersionSource=;
GitBaseVersionMajor=0;
GitBaseVersionMinor=1;
GitBaseVersionPatch=0;
GitCommits=0;
GitTag=v2.1-1-g8860bcb;
GitBaseTag=v2.1;
GitSemVerMajor=0;
GitSemVerMinor=1;
GitSemVerPatch=0;
GitSemVerLabel=;
GitSemVerDashLabel=;
GitSemVerSource=Default

GitInfo sees the tag, so why is it using the default 0.1.0 as the BaseVersion and SemVer?

Shouldn't GitCommits be 1, since I'm 1 commit ahead of the tag?

Thanks for any clarification.

Hi, i started to use GitInfo for versioning and while checking generated version detail, seems like something is wrong

AssemblyInfo

Git History

Application Detail

Any help would be appreciated, Thanks