Enable tests on netcoreapp3.1

[qmfrederik]

I'm prototyping work related to #505. The managed Git implementation, at the moment, uses Span<T> and friends, and targets netcoreapp3.1.

I retargeted the project and tests to run on netcoreapp3.1 and came across a couple of test failures, which this PR attempts to resolve:

• The AssemblyVersionInfo task throws no error when targeting a language which is not supported
• RuntimePath appears to be ./runtimes instead of ../runtimes
• SevenZipNET does not target netcoreapp, and is only used in a test which is skipped. I have methods which rely on SevenZipNET throw a PlatformNotSupportException.

[qmfrederik]

@AArnott - NativeVersionInfo_CreateNativeResourceDll still fails. Do you know if MSBuild Core supports vcxproj projects?

[AArnott]

NativeVersionInfo_CreateNativeResourceDll fails locally for me too. MSBuild certainly does support vcxproj, but I don't remember why it fails locally. But it passes in CI.

[AArnott]

That said, interestingly that vcxproj test passes on net461 in CI but fails on netcoreapp3.1. If we can't figure out how to fix it, we can disable it using something like this on the test method:

#if NETCOREAPP
[Trait("TestCategory", "FailsOnAzurePipelines")]
#endif

[qmfrederik]

93d9d30 might do the trick by making the test conditional - the test won't work if the v142 toolset is not installed or the Windows 10 SDK could not be resolved.

I don't fully understand why the test would succeed on NetFx and fail on NetCore, though, perhaps somebody with a deeper understanding of the VC toolset can explain (or we just skip the test on Azure, like you suggest) :).

[AArnott]

I suspect it's because under .NET Core, the msbuild installation comes from the .NET Core SDK, which doesn't have C++ extensions installed. But when run under .NET Framework, the msbuild found comes from the VS installation which does have C++ installed.

I'm concerned though about pinning too precise of a path here based on specific toolset versions. This seems like it will silently cause the test to start skipping when Azure Pipelines updates from the 14.2 VC toolset to something later. I'd be more comfortable with a test that won't stop running where it currently runs without raising a fuss. Can we perhaps instead use #if NETCORE to skip the test so it always runs on .NET Framework?

[qmfrederik]

Sure, no problem.

PS - I've noticed CI doesn't get triggered automatically on a push to a PR. Is that something that can be fixed?

[AArnott]

I've noticed CI doesn't get triggered automatically on a push to a PR. Is that something that can be fixed?

I sure hope so. It's broken everywhere. Please consider voting that ticket up.

[AArnott]

Thanks.