.NET Core 3.1 as a new target platform (#48)

[villelaitila]

Getting it now compiled on netcoreapp3.1 tfm

---

This change is 

[3F]

Thanks for contributing to MvsSln!

According to your initial build error on linux, does this really help? :) I mean TargetFrameworks still contains netfx targetting net40;net472 that can produce the same error (I can't check it yet to be sure).

Anyway, I think it would be good to split it using a specific platform, like here: https://github.com/3F/IeXod/blob/e96a6d6f5dc01e9241360679a7e952985700e93a/src/common.props#L57-L73

Here's how to detect linux, for example https://github.com/3F/IeXod/blob/e96a6d6f5dc01e9241360679a7e952985700e93a/src/common.props#L25

$([MSBuild]::IsOSPlatform('linux'))

That is, for the most common solution, it might be something like ~

<TargetFrameworks Condition="'$(OsEnvironment)'=='windows'">net40;net472;netstandard2.0;netcoreapp2.1</TargetFrameworks>
<TargetFrameworks Condition="'$(OsEnvironment)'=='linux'">netstandard2.0;netcoreapp2.1</TargetFrameworks>

What do you think?

[villelaitila]

These changes make dotnet build MvsSln.sln -f netcoreapp3.1 work, which is fine for me now. Adding the complexity for "windows" and "linux" would make it unmaintainable because there will also be anyway need for adding also OSX and what not. And that would make it much more fragile.

[3F]

These changes make dotnet build MvsSln.sln -f netcoreapp3.1 work, which is fine for me now.

It will just compile for a specific framework in this case while other user will face the error again

Also, you can even try the same build using supported .NET Core 2.1. I've just checked it on newly created linux machine:

Build started git clone -q --branch=master https://github.com/3F/MvsSln.git /home/appveyor/projects/mvssln-2d2c2 git checkout -qf 9ce5885282d65ee32bfc03808c83c1113c1928e3 Running "build_script" scripts dotnet build -f netcoreapp2.1 Microsoft (R) Build Engine version 16.8.0+126527ff1 for .NET Copyright (C) Microsoft Corporation. All rights reserved. Determining projects to restore... Restored /home/appveyor/projects/mvssln-2d2c2/MvsSlnTest/MvsSlnTest.csproj (in 9.81 sec). Restored /home/appveyor/projects/mvssln-2d2c2/MvsSln/MvsSln.csproj (in 14.74 sec). MvsSln -> /home/appveyor/projects/mvssln-2d2c2/MvsSln/bin/Debug/netcoreapp2.1/MvsSln.dll MvsSlnTest -> /home/appveyor/projects/mvssln-2d2c2/MvsSlnTest/bin/Debug/netcoreapp2.1/MvsSlnTest.dll Build succeeded. 0 Warning(s) 0 Error(s) Time Elapsed 00:00:14.79 Build completed

CI: dotnet build -f netcoreapp2.1

Adding the complexity for "windows" and "linux" would make it unmaintainable because there will also be anyway need for adding also OSX and what not.

But in fact these are different platforms that need to be considered independently anyway. Such for msbuild, IeXod projects etc.

And that would make it much more fragile.

If compare .NET projects and let's say projects on native C++, the second will be more fragile even between the same platform due to platform toolset, target platform version, etc. For .NET this usually relies only on minimal compatible version of the required target platform and dependencies with the same criteria which btw we don't have many.

So! @villelaitila I do not force you to make big changes of course :) but changes in this PR are a bit inconsistent as a solution for #48.

I recommend either provide only a few information in Readme for how to build this on linux to avoid the error MSB3644, or additionally split properties as it was mentioned above.

Let me know if you have questions or problems. Thanks!

[3F]

oh, maybe build.sh as a third option

[3F]

Unfortunately I have not received any reaction after 4 months. Today, this PR is no longer relevant because projects file is now uses common.props with OsUnixLike flag and NetCoreTFM/NetStdTFM splitting

Here's build example on Ubuntu2004 worker image: https://ci.appveyor.com/project/3Fs/mvssln-2d2c2/builds/40491644#L1

Feel free to contribute anything later. Thanks for using,