libgit2 / libgit2sharp.nativebinaries

MIT License
28 stars 62 forks source link

Compatibility with MSBuild 14 #97

Closed robi-wan closed 5 years ago

robi-wan commented 5 years ago

Building a project which relies on LibGit2Sharp.0.26.0 (and therefore LibGit2Sharp.NativeBinaries.2.0.267) fails with this error (output formatted):

<project>\packages\LibGit2Sharp.NativeBinaries.2.0.267\build\net46\LibGit2Sharp.NativeBinaries.props(1,1):
error MSB4041: The default XML namespace of the project must be the MSBuild XML namespace.
If the project is authored in the MSBuild 2003 format, please add xmlns="http://schemas.microsoft.com/developer/msbuild/2003" to the <Project> element.
If the project has been authored in the old 1.0 or 1.2 format, please convert it to MSBuild 2003 format.

Since MSBuild 15.0 the mentioned attribut is optional:

Also the Xmlns attribute [of the Project element] is now optional.

Older versions of MSBuild (e.g. 14.0) do require this attribute.

This change adds this attribute to the Project element.

After this patch the build (with the recent version of LibGit2Sharp.NativeBinaries from GitHub) again fails:

<project>\packages\LibGit2Sharp.NativeBinaries.2.0.267\build\net46\LibGit2Sharp.NativeBinaries.props(9,98):
error MSB4066: The attribute "TargetPath" in element <ContentWithTargetPath> is unrecognized.

Tweak the ContentWithTargetPath element: Change attributes TargetPath and CopyToOutputDirectory to inner elements.

This maybe also fixes Can't parse project with reference to libgit2sharp.

I propose this change because we build the project (which uses libgit2sharp) on a machine which has MSBuild 14.0 as the most recent version of MSBuild installed (and for various reasons the machine cannot be equipped with a more recent version of MSBuild).

bording commented 5 years ago

Thanks for the PR, but at this time I don't think I'm interested in making these changes. I wrote these the way I did intentionally, knowing that it would require VS 2017 and MSBuild 15 as a minimum to use them.

I don't think it's unreasonable to have these versions be required, as VS 2015 and MSBuild 14 are rather old at this point.

VS 2017 is already over two years old, and VS 2019 was just released.

robi-wan commented 5 years ago

Hi, thanks for looking at this PR. I am sorry to hear that you do not want to merge it but that's legit regarding you do not want to support Visual Studio 2015/MSBuild 14.0.

I work for a machine manufacturer - we have slow update/upgrade cycles: One of our deployed applications still has to support Windows XP. (We use Visual Studio 2010 for it's development.)

For internal development we can use slightly more recent software. Until now we used Visual Studio 2015 Update 3 for the application which recently got a dependency on LibGit2Sharp.

I'll see if we can use this workaround (direct reference) or if we can update the used version of Visual Studio.

BTW: Thanks for your time and effort creating and maintaining this project!