enable support for .NET Fx 4.6.1 <-> .NET Standard 2

[0x53A]

This should be finished, but I need to do some manual tests.

Let's run CI.

---

What

This allows users to opt-in to support between .NET Fx 4.6.1 and .NET Standard 2.0.

How

You can set EnableNetFx461NetStandard2Support in the app.config of paket.exe (works both for "normal" paket.exe and magic-mode paket.exe).

If you use Paket.Core as a Library, you can set

DotnetToolingSupport.mode <- ToolingSupportMode.ToolingSupportNetSDK2

Caveats

This is a hacky workaround for a shoddy implementation by Microsoft in the .NET SDK 2.x.

After setting this flag, delete and regenerate your lockfile. Just running install is not enough.

Ensure that the flag is consistently either always on, or always off. Check paket.exe.config into source control.

---

supersedes #3248

fixes #3004 (it would then add the .NET Standard 2 dll for .NET 4.6.2)

fixes #2986
fixes #2705

ref #2391

and see https://twitter.com/terrajobst/status/1032025428242849793

[0x53A]

that error looks unrelated

[forki]

can you please merge with master?

[forki]

woud be good to have the setting as a group setting

[0x53A]

Hi @forki, sorry for the delay, I've merged latest master and let's see what CI says.

would be good to have the setting as a group setting

when I started with this, i took a look at how a proper implementation could be done, and it was a lot of work, touching almost everything.

You would need to parametrize FrameworkIdentifier.RawSupportedPlatforms by this flag, and pass it everywhere.

---

After CI is green I'll do another manual test, I think it worked ... almost half a year ago, but just to be sure ...

(And maybe add a test or two)

[0x53A]

I wanted to add an end2end integration test, but hit an unexpected issue:
With PR #2664 I made it so that the build doesn't use the local reference assemblies for compilation, but instead from a NuGet package (0x53A.ReferenceAssemblies.Paket).

Currently this package only contains the ref-assemblies for net45, so I can't create a test project with .net461.

Adding the ref-assemblies for net461 into this package would double the package size (from 100MB extracted to 200MB extracted), which i don't think is worth it.

So instead I've create a small unit test which doesn't check compilation, but just resolving.

[0x53A]

Manual tests for both direct execution and bootstrapper exection were Ok. If you use the bootstrapper, then you also need the latest paket.exe downloaded, an old one from cache obviously doesn't understand the new flag.

[0x53A]

merged master, now build is green again

[marcinsmialek]

What's the status of this PR?

I know we have .NET Framework 4.8 now, but some people refuse to install anything newer than 4.6.1 😒

[forki]

We can't take it as it. We need a group setting for it since it's breaking and even MS admitted it is not correct.

[0x53A]

It's not directly breaking, since you would have to enable it in the app.config manually. So if you do nothing, nothing changes.

Can you maybe take a quick look at an implementation strategy?

If you want to make it a group setting, then the hack with the global mutable field isn't enough, you would have to parametrize SupportCalculation.getSupportedPlatforms etc by this flag. It would need to be passed down, and this would touch almost everything.

At least that was my conclusion a year ago, and the reason why I settled on the app.config "hack".

[forki]

would it work with paket global tool or magic mode?
I feel this should at least be a setting in the deps file

[matthid]

Just note that depending on this will subtly prefer netstandard1.5 in some situations over netstandard2.0 (for example in net462).
The possible impact of this is smaller as expected as we forward all packages to nuget in the final step, but the list of packages might differ.

[0x53A]

would it work with paket global tool or magic mode?

It should already work as is with magic mode, just set the app.config of the bootstrapper.

I feel this should at least be a setting in the deps file

I guess that would be possible to make work - read the setting, then set the global variable before doing any other operations.

It would be treated similar to the "version" global setting.

[forki]

Yes. That would be great Lukas Rieger <[email protected]> schrieb am Fr., 20. Sep. 2019, 18:21:

…

would it work with paket global tool or magic mode? It should already work with magic mode, just set the app.config of the bootstrapper. I feel this should at least be a setting in the deps file I guess that should work - read the setting, then set the global variable before doing any other operations. It would be treated similar to the "version" global setting. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3447?email_source=notifications&email_token=AAAOANGGMYLNPGHKE4MQ3HDQKTZ7HA5CNFSM4GIL56J2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7HGQXI#issuecomment-533620829>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAOANHS4QKGP645YGW3FWLQKTZ7HANCNFSM4GIL56JQ> .

[xperiandri]

@0x53A, where to put

You can set EnableNetFx461NetStandard2Support in the app.config of paket.exe (works both for "normal" paket.exe and magic-mode paket.exe).

What is the structure of app.config? I can't find such a setting anywhere

[0x53A]

As this PR wasn't merged, there is no such feature.

It wasn't merged because the app settings is more of a hack, and it would have been preferable to add a setting to the paket.dependencies.

Though at that point I didn't have any more time / energy.

Theoretically it would have been in the appSettings:

    <?xml version="1.0" encoding="utf-8" ?>  
    <configuration>  
      <appSettings>  
        <add key="EnableNetFx461NetStandard2Support" value="true"/>  
      </appSettings>  
    </configuration>  

[RagingKore]

any news on this?

[xperiandri]

@0x53A do we need this or should it be updated?

[marcinsmialek]

Due to the end-of-life of .NET 4.6.1, it was necessary to update the .NET Framework version, where possible.
Most of the migrations I've seen were to .NET 4.7.2 and 4.8.0, which support .NET Standard 2 well. I assume that such upgrades are prevalent, which would diminish the significance of this change. However, I have also encountered 4.6.1 -> 4.6.2 transitions too.

The 4.8.1 version looks good, but it's not supported on Windows Server 2019, and we can treat it as 4.8.0.

If you choose to implement a flag that allows Paket to treat 4.6.1/4.6.2 as .NET Standard 2 compatible, I think that it should also be easy to remove to simplify the codebase when the impact will decrease over time.
Perhaps the version match could be delegated and possible to override by an extension?