fsprojects
enable support for .NET Fx 4.6.1 <-> .NET Standard 2
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 https://github.com/fsprojects/Paket/pull/3248
fixes https://github.com/fsprojects/Paket/issues/3004 (it would then add the .NET Standard 2 dll for .NET 4.6.2)
fixes https://github.com/fsprojects/Paket/issues/2986 fixes https://github.com/fsprojects/Paket/issues/2705
ref https://github.com/fsprojects/Paket/pull/2391
and see https://twitter.com/terrajobst/status/1032025428242849793
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)
I wanted to add an end2end integration test, but hit an unexpected issue: With PR https://github.com/fsprojects/Paket/pull/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.
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.
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 😒
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.
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".
would it work with paket global tool or magic mode? I feel this should at least be a setting in the deps file
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.
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 https://github.com/fsprojects/Paket/pull/3447?email_source=notifications&email_token=AAAOANGGMYLNPGHKE4MQ3HDQKTZ7HA5CNFSM4GIL56J2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7HGQXI#issuecomment-533620829, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAOANHS4QKGP645YGW3FWLQKTZ7HANCNFSM4GIL56JQ .
@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
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>
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?