Building using dotnet build fails for .NET Standard library project

[jpierson]

I'm using the latest pre-release of GitVersionTask (4.0.0-beta0011) on a .NET standard library project and it seems to work from Visual Studio 2017 but not from the command line using dotnet build. I'm targeting netstandard1.2.

I wasn't sure whether this would work at all. I started off looking around for an implementation that installs a GitVersion package as a DotnetCliToolReference in an SDK csproj file. With nothing conclusive from that or from other .NET Core related issues (ex. #647) I figured I should just try adding the package reference and see what it does. I was happy at first to see it was working when building the solution from Visual Studio but building using dotnet build gives me the following error.

Microsoft (R) Build Engine version 15.1.545.13942
Copyright (C) Microsoft Corporation. All rights reserved.

C:\Users\me.nuget\packages\gitversiontask\4.0.0-beta0011\build\GitVersionTask.targets(45,5): error MSB4062: The "GitVersionTask.WriteVersionInfoToBuildLog" task could not be loaded from the assembly C:\Users\me.nuget\packages\gitversiontask\4.0.0-beta0011\build\GitVersionTask.dll. Could not load file or assembly 'Microsoft.Build.Utilities.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL'. The system cannot find the file specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. [C:\Users\me\source\myproj\src\MyProj\MyProj.csproj]
C:\Program Files\dotnet\sdk\1.0.0-rc4-004771\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.targets(92,5): error : Cannot find project info for 'C:\Users\me\source\myproj\src\MyProj\MyProj.csproj'. This can indicate a missing project reference. [C:\Users\me\source\myproj\src\TestCore\TestCore.csproj]

Build FAILED.

C:\Users\me.nuget\packages\gitversiontask\4.0.0-beta0011\build\GitVersionTask.targets(45,5): error MSB4062: The "GitVersionTask.WriteVersionInfoToBuildLog" task could not be loaded from the assembly C:\Users\me.nuget\packages\gitversiontask\4.0.0-beta0011\build\GitVersionTask.dll. Could not load file or assembly 'Microsoft.Build.Utilities.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL'. The system cannot find the file specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. [C:\Users\me\source\myproj\src\MyProj\MyProj.csproj]
C:\Program Files\dotnet\sdk\1.0.0-rc4-004771\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.targets(92,5): error : Cannot find project info for 'C:\Users\me\source\myproj\src\MyProj\MyProj.csproj'. This can indicate a missing project reference. [C:\Users\me\source\myproj\src\TestCore\TestCore.csproj]
0 Warning(s)
2 Error(s)

Time Elapsed 00:00:01.09

According to the documentation:

Support for CoreCLR with dotnet build is coming soon.

Is there anywhere I can follow along with the work being done for getting GitVersionTask or some form of automated solution that works for .NET library projects?

[JakeGinnivan]

@onovotny any thoughts? :)

[clairernovotny]

Yeah, it cannot work with dotnet build. dotnet build uses the CoreCLR and the tasks are currently compiled for the desktop framework. You have to use msbuild.exe /t:restore,mbbuild.exe /t:build, and msbuild.exe /t:pack as the equiv of dotnet restore, dotnet build and dotnet pack.

Once GitVersion has .NET Standard versions of the underlying assemblies, we can create .NET Standard build task and support it easily. I believe LibGit2Sharp now has this support as NerdBank.GitVersioning has a .NET Standard version now that uses LibGit2Sharp.

[TAGC]

Which of GitVersion's dependencies are currently blocking progress on the migration?

[asbjornu]

@TAGC: Not sure. Here's a dump of GitVersion's packages folder:

• ApprovalTests.3.0.11
• ApprovalUtilities.3.0.11
• Caseless.Fody.1.4.2
• FluentDateTime.1.13.0
• Fody.1.29.4
• GitTools.Core.1.2.1-beta0001
• GitTools.Testing.1.1.1-beta0001
• ILRepack.2.0.12
• JetBrainsAnnotations.Fody.1.0.5.0
• LibGit2Sharp.0.23.0-pre20160922233542
• LibGit2Sharp.NativeBinaries.1.0.160
• Microsoft.CodeAnalysis.Analyzers.1.1.0
• Microsoft.CodeAnalysis.CSharp.1.3.2
• Microsoft.CodeAnalysis.Common.1.3.2
• Microsoft.CodeAnalysis.VisualBasic.1.3.2
• ModuleInit.Fody.1.5.9.0
• Mono.Cecil.0.9.6.4
• NSubstitute.1.10.0.0
• NUnit.3.6.0
• NUnit3TestAdapter.3.7.0
• Newtonsoft.Json.8.0.3
• ObjectApproval.1.3.0
• PepitaPackage.1.21.4
• Shouldly.2.7.0
• System.Collections.4.3.0
• System.Collections.Immutable.1.3.1
• System.Diagnostics.Debug.4.3.0
• System.Globalization.4.3.0
• System.Linq.4.3.0
• System.Reflection.Metadata.1.4.2
• System.Resources.ResourceManager.4.3.0
• System.Runtime.4.3.0
• System.Runtime.Extensions.4.3.0
• System.Threading.4.3.0
• TestStack.ConventionTests.3.0.0
• Visualize.Fody.0.4.5.0
• YamlDotNet.3.8.0

I assume most of these need to be ported to .NET Standard before GitVersion can?

[conniey]

@asbjornu Yes... or an alternative would have to be found for them.

The ones that do not exist are:

• ApprovalTests.3.0.11 (Add support for .NET Core approvals/ApprovalTests.Net#162)
  • ApprovalUtilities.3.0.11
  • ObjectApproval.1.3.0
• Fody.1.29.4 (Fody mscorlib not found on .NETStandard project Fody/Fody#280)
  • Caseless.Fody.1.4.2
  • Visualize.Fody.0.4.5.0
  • ModuleInit.Fody.1.5.9.0
  • JetBrainsAnnotations.Fody.1.0.5.0
• LibGit2Sharp.0.23.0-pre20160922233542 (PR: Target .NET Standard 1.3 libgit2/libgit2sharp#1318)
  • GitTools.Core.1.2.1-beta0001 (Uses LibGit2Sharp)
  • GitTools.Testing.1.1.1-beta0001
• PepitaPackage.1.21.4
• TestStack.ConventionTests.3.0.0 (Make the nuget package compatible with NETCore TestStack/TestStack.ConventionTests#77)
• YamlDotNet.3.8.0 (PR: Port to .NET Standard aaubry/YamlDotNet#244)

[dazinator]

Just hit this when running dotnet test on an xunit project, that has a project reference to the project with the gitversion task. I am not sure what the equivalent of dotnet test is for msbuild, however managed to workaround this by:

1. Build the test project first using msbuild.
2. dotnet test --no-build to execute the tests.

[el2iot2]

Just saw on Twitter that the PR for LibGit2Sharp got merged. That brings this issue one step closer to resolution, it would seem.

[el2iot2]

Yep after a quick survey, only PepitaPackage and ApprovalTests don't have netstandard support?

[dazinator]

I don't think ApprovalTests should matter as this is a build time only dependency surely - (i.e for running tests) so shouldn't be a dependency that is forced onto consumers?

[dazinator]

Also just a note to say that even though calling msbuild instead of dotnet cli will provide a workaround for some scenarios, for others, like dotnet ef I can't find any equivalent msbuild commands so this remains a problem.

[dazinator]

I have looked at the dependencies and filtered down the relevent ones for gitversiontask which are:

  <package id="GitTools.Core" version="1.2.1-beta0001" targetFramework="net40" />
  <package id="ILRepack" version="2.0.13" targetFramework="net40" />
  <package id="LibGit2Sharp" version="0.23.0-pre20160922233542" targetFramework="net40" />
  <package id="LibGit2Sharp.NativeBinaries" version="1.0.160" targetFramework="net40" />
  <package id="YamlDotNet" version="3.8.0" targetFramework="net40" />

[dazinator]

Notable we would need to add support for netcore to GitTools.Core first.

[dazinator]

So the blockers seem to be:

• GitTools.Core
• ILRepack: https://github.com/gluck/il-repack/blob/master/ILRepack/packages.config

YamlDotNet has a .NET standard version of the package that I assume we could switch too. https://www.nuget.org/packages/YamlDotNet.NetCore/

[asbjornu]

@dazinator: GitTools.Core should be a simple port. But I'm not quite sure what we're using ILRepack for. @JakeGinnivan?

[dazinator]

@asbjornu I started on the port of GitTools.Core but could not get it building yet. Its in a feature branch - If curious see: GitTools/GitTools.Core#40

[dazinator]

I have got gittools.core building for net standard now (under appveyor). Nuget package is here: https://ci.appveyor.com/project/GitTools/gittools-core/build/1.2.1-PullRequest.42+33.build.122/artifacts

[dazinator]

Im planning on starting the PR for this, this week. Not sure what to do about ILRepack just yet but we shall see!

[dazinator]

The msbuild task needs to be built for netdesktop and netstandard, and the targets need to load the correct assembly at build time based on detecting whether its bulding on netcore or not. See: GitTools/GitLink#168 (comment)

[dazinator]

Hit a hurdle. The continua CI support relies on RegistryView which isn't available in netstandard1.3.. so for now I'm excluding ContinuaCI from netstandard build..

[dazinator]

Hit another hurdle.. System.Web is used for it's Databinder class.. this is not available under netstandard. Seems like we should get rid of this dependency permanantly..

[asbjornu]

Any reference to System.Web is a reference too many. If it's possible to circumvent Databinder, then go for it! What's it used for, btw?

[dazinator]

It looks like it's used to format version numbers in line with a customisable template. I won't be able to look at this again for a while now, so happy for someone else to give this ago. Perhaps I should raise "Remove / Replace System.Web" as a new / separate issue?

[asbjornu]

@dazinator: Yes, that would be a bit easier to tackle. 👍

[dazinator]

@kieranbenton
Cool, i'll try and get a nuget package out somewhere. Yeah my libgit2sharp PR fixed the issue for netcore running on windows only and remains in my own fork of libgit2sharp. I will switch to that package temporarily in this PR, so we can atleast start testing under windows. In the meantime I have an issue open over at the UtilPack msbuild task factory project, which can hopefully fix it fully accross all platforms, and then we can adopt the standard libgit2sharp package again (fingers crossed)

[dazinator]

Right we think we have resolved the libgit2sharp native dependency issue now. So no need to use my fork of libgit2sharp after all. Next thing I / we need to do is get the appveyor build working and publishing nuget packages similar to gittools.core. anyone can feel free to jump in and look at the appveyor build / travis builds of the netstandard PR, Just drop a note if you do so that we dont overlap.

[kieranbenton]

@dazinator can you grant me access to appveyor to take a look? Haven't managed to find any details in the wiki of how I might have a poke around to see how the build is failing.

[dazinator]

@kieranbenton - I am not sure I have the powers.. I only get access to AppVeyor because I was added to the GitTools github organisation, however I don't have the power to add others. @GitTools/developers who can help?

[asbjornu]

Seems like I'm an administrator, but I have no idea how to grant someone else permissions. Ideas?

[kieranbenton]

I'm not an appveyor expert unfortunately (though ive poked my way around most other CI/CD systems) - so if its simpler than getting me access maybe someone else can have a look and I can just do some QA for you?

[dazinator]

@asbjornu - I assume they have to be added to the github GitTools organisation.

[dazinator]

My plan for the PR is to get the builds working so it piblishes a nuget package which will support netcore / netstandard 1.X projects. Then after that, upgrade to the next version of libgit2sharp which requires netcoreapp2.0 / netstandard 2.0. That way we get an interim package published that will support anyone stuck on 1.X, but moving forward we will require 2.0 becuase thats what libgit2sharp now requires.

[TsengSR]

Any progress on this?

@dazinator: Do you thing this makes any sense at all to have a 1.x version running, just for the sake of it? People who initially started with ASP.NET Core 1.x and are stucked to it didn't had the opportunity to use GitVersion at all so they already managed to come out w/o it or upgraded to 2.0 already (as there are other benefits).

People starting new project will start with 2.0 already, since it has way wide and more APIs. So there shouldn't be too much people who use 1.x already and even less who use GitVersion with it, since it doesn't work with the new csproj structure. At least not fully (assembly versioning)

[dazinator]

@TsengSR
Targeting netstandard 1.x isnt really the hold up for this PR. That work has been done and I removed things like windows registry api calls and system.web calls in the process. All good things imho. You can build this branch locally and run gitversion on dotnet core with you want to try it out.. afaik its working. The blocker for this PR at the moment is just that the appveyor builld is failing for some reason and it needs someone to investigate and get the build fixed and publishing nuget packages again.

You are more than welcome to take a fork and retarget the PR in your own branch to target netstandard2.0 if you want. My plan after this is building and publishing packages again is to upgrade to netstandard 2.0 anyway. Alternatively if you want to assist (this goes for anyone) please investigate the appveyor build! :-)

[dazinator]

Oh and also I have production asp.net core 1.1 apps, building with dotnet sdk / cli 1.x targeting net461 that I'd like the gitversion msbuild task to work for so thats my vested interest for wanting to get a 1.x build before upgrading to 2.

[tmds]

The blocker for this PR at the moment is just that the appveyor builld is failing for some reason and it needs someone to investigate and get the build fixed and publishing nuget packages again.

[tmds]

The blocker for this PR at the moment is just that the appveyor builld is failing for some reason and it needs someone to investigate and get the build fixed and publishing nuget packages again.

@dazinator did you see the edits by @gabrielweyer in #1269 (comment)?

[dazinator]

@tmds Nope I missed it! But I will look at that now!

[thestonehead]

Is this going to be released any time soon? It would make our CI much easier.

[pbalaga]

Any news on this one? I think there is still a lot of interest in it. :) What are the blockers as of now?

[dazinator]

Checkout the pr named Netstandard. It has instructions. Short answer is yes you can do this now. Not yet been merged but you can try the PR nuget packages. Let me know how you get on!

[pbalaga]

Sounds good! Thanks!

[TsengSR]

Checkout the pr named Netstandard. It has instructions. Short answer is yes you can do this now. Not yet been merged but you can try the PR nuget packages. Let me know how you get on!

@dazinator: That sounds good though, but can that one be used with the TFS/VSTS pipeline? The only available package for VSTS fromt he store is 3.6.5 one.

It would be cool to have the 4.x .NET Standard bits packaged within it, and allows us to change the Version via the little "version" drop-down menu? Microsoft does the same with the TFS/VSTS BuildTasks for .NET Core, where they'd set "1." versions as default and "2. (Preview)" (its out of preview by now already) could be chosen manually when needing the newer version?

I played around with the the GitVersionTask nuget packages including into your project on our VSTS build pipeline, but right now it only works on the hosted Windows Pipelines, not on the linux based ones (due to lack of mono and .NET Core/Standard support).

Or is the VSTS BuildTask Extension obsolete now with the 4.x versions and we just need to use the dotnet core build task and invoke the cli?

One bit success I had a few months ago with the Extensions and the nuget packages available form the official nuget feeds (4.0 beta12 preview iirc) was to generate the appropriately assembly versions in AssemblyInfo.cs, but only with the Extension and on Windows Hosted Build Agent.

[dazinator]

That sounds good though, but can that one be used with the TFS/VSTS pipeline? The only available package for VSTS fromt he store is 3.6.5 one.

The TFS package, and the GEM package aren't being built from the PR branch yet unfortunately.
To Run on Linux you might try:

1. Using the dotnet core based docker container?
2. Using GitVersionTask ? (This will stamp your assemblies during a dotnet build or an msbuild) so doesn't require mono.
3. Install the GitVersion.CommandLine.DotNetCore nuget package - then invoke that using dotnet cli during your build process. This should run on linux as long as dotnet core is installed.

Do any of those options help?

Customising the TFS package is beyond my experience, I would like to get the artifcat being built in the PR branch as a first step!

[TsengSR]

Will try that in 2 or 3 after my vacation.. GitVersion on TFS/VSTS is a bit of a strange beast.

On one side we need the assemblies to have a specific version so it can version it on the other side the nuget packages and the build itself, so a mix of both NugetPackage based tasks and cli is required to get proper versioning for CI/CD.

[dazinator]

Any joy on this?

[fleed]

@dazinator how do I get the PR nuget packages?

[dazinator]

@fleed you donate £10 into my bank account and then I email you the package :-)

On a more seripus note, this is how:

Checkout the pr named Netstandard. It has instructions. Short answer is yes you can do this now. Not yet been merged but you can try the PR nuget packages. Let me know how you get on!

it tells you about the CI nuget feed you need to add (hosted on appveyor) and the nuget package version you need to reference.

[richardgavel]

Are we saying there almost needs to be a matrix of GitVersion/NET Core SDK version combinations that are known to work together?

[asbjornu]

I believe that after upgrading to LibGit2Sharp 0.26 in #1713, this problem should be fixed. Can you please try the latest build of GitVersion and report back whether it fixes this problem or not? Please reopen this issue if the problem persists.