Build against dotnet core msbuild assemblies

[GeertvanHorrik]

As suggested by @dazinator in #87

If your msbuild task is built on the full desktop version of the msbuild assemblies (i.e if these references are the desktop version of msbuild: https://github.com/GitTools/GitLink/blob/develop/src/GitLinkTask/GitLinkTask.csproj#L53) then dotnet build won't work as the dotnet cli tooling (an the version of msbuild used) will complain that it can't load the task, as the assembly is not compatible with netcore. I believe you have to build your task against the netstandard compatible msbuild assemblies - I.e: https://www.nuget.org/packages/Microsoft.Build.Framework/15.3.0-preview-000388-01

@AArnott , you think we can just port to the new dotnet tooling?

[dazinator]

And for more info - this same issue is currently also affecting the GitVersion msbuild task, so can see their for more details: https://github.com/GitTools/GitVersion/issues/1175

[AArnott]

Now that libgit2sharp has a .NET Core variety, yes it's conceivable that we could offer .NET Core build support within GitLink as well. Note that it's not a matter of simply retargeting to MSBuild's .netstandard libraries, for two reasons:

1. that would break support for any existing customers that are still on MSBuild 14
2. even msbuild 15.1 doesn't guarantee all the facade assemblies are present from .net standard

So actually any MSBuild task that intends to work both in the dotnet build and msbuild.exe worlds must be compiled twice. I've had to do this with a few of my projects already, so I could apply the change here too.

Keep in mind though that gitlink doesn't support the new portable PDB format that is the default with projects that are usually built with dotnet build. So if you're in that world, sourcelink is probably the way to go and already supports dotnet build. So I'm curious how many potential customers would really appreciate gitlink supporting dotnet build while still using full Windows-only PDBs.

[GeertvanHorrik]

Good point, thanks for providing this feedback. We might look into moving towards SourceLink in the future (but it's not necessary on the short run). I suggest sticking with 2.4.1 for now, then we can slowly migrate to SourceLink in the future.

[dazinator]

@AArnott

So actually any MSBuild task that intends to work both in the dotnet build and msbuild.exe worlds must be compiled twice. I've had to do this with a few of my projects already, so I could apply the change here too.

I am in the process of doing this for gitversion's msbuild task :-( Do you happen have an example nuspec that shows how to package both of the assemblies (I.e netstandard and desktop) within the same package? I am assuming you have to duplicate the targets also - or do you have one targets file and load the correct assembly based on some msbuild condition in the targets that detects what its running under?

Any pointers here much appreciated - I'd prefer not to have to resort to 2 seperate nugget packages.

[AArnott]

Two packages is not required. And you can do with just one .targets file too, which has a Condition on all UsingTask elements so that it imports the MSBuild Core task assembly or the MSBuild (full) task assembly as appropriate. I've had to do this so much (and get bruised in so many places along the way learning how to deal with it) that I wrote a NuGet package to help you write such nuget packages: https://github.com/AArnott/Nerdbank.MSBuildExtension

As a sample that does not use the above nuget package, you can refer to Nerdbank.GitVersioning:

• .targets file that follows the multiple UsingTask pattern.
• MSBuild task project file that builds once for each platform
• NuGet package from which you can study the nuspec file if you wish.

[dazinator]

Thank you - much appreciated, that should save me quite a bit of time there!