Repository navigation
Drop support for .NET Framework 4.0 - 4.6 (e.g. require 4.6.1, which supports .NET Standard 2.0) #1299
Description
Activity
.NET Standard before 4.7.2 has unfixed bugs, so that should be the target.
Are any of those bugs important for us?
- Dropping the old stuff is fine by me. Support for OSPlatform (in .NET Framework 4.7.1) would allow removing some hacky code to find the current platform. For Unity's needs we only need support for whatever 2019.4 supports.…On Tue, Dec 1, 2020 at 1:42 PM Victor ***@***.***> wrote: Are any of those bugs important for us? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1299 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADYTLBNCX7LDGP4POQPPEDDSSU2KRANCNFSM4UIEUTQA> .-- Benoit Hudson CTO, Imaginary Spaces http://imaginary-spaces.com tel: 1.514.566.0289
Do you happen to know what the support-level of Unity 2019.4 is? Should be enough to know what Mono version is linked.
- Unity 2019.4 uses Mono 5.11 with /langversion:latest which per the documentation for Mono 5.10 should mean 4.7.1 ; it does this both when claiming to support .NET Standard 2.0 and .NET 4.x In testing, I can indeed use OSPlatform.X on Unity 2019.4, for X = Windows, Linux, or OSX -- but not for FreeBSD, which requires 5.0 (Unity doesn't run on FreeBSD anyway).…On Wed, Dec 2, 2020 at 3:56 AM Benedikt Reinartz ***@***.***> wrote: Do you happen to know what the support-level of Unity 2019.4 is? Should be enough to know what Mono version is linked. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1299 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADYTLBOJFOZKQM65LKKTOTLSSX6KVANCNFSM4UIEUTQA> .-- Benoit Hudson CTO, Imaginary Spaces http://imaginary-spaces.com tel: 1.514.566.0289
@filmor apologies for hijacking an old thread, can create a new issue if you want.
Are there any actual blockers which prevent at least limited support of 4.6.1 as a part of .NET Standard 2.0?
I needed that and while I know that 4.6.1/Standard 2.0 situation is messy in .NET in general, I've:
- patched CLR Loader to compile for net461 (
LPUTF8Str->IntPtrwith manual conversion,ValueTuple->Tuple), - referenced ValueTuple and InteropServices in
Python.Runtime.csproj, - made a build step to copy
netstandard.dllassembly to theOutDir,
and only if I switch the target framework to net461 for Python.Runtime.csproj, then I am able to run a simple hello world successfully from Python in a 4.6.2 environment. If I switch target back to
netstandard2.0-- the assemblies disappear from the output, and even if I add them back - I for some reason get errors on loading them which I currently am not sure how to resolve:Failed to initialize pythonnet: System.TypeInitializationException: The type initializer for 'Delegates' threw an exception. ---> System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime.InteropServices.RuntimeInformation, Version=0.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. at Python.Runtime.Platform.LibraryLoader.get_Instance() at Python.Runtime.Runtime.Delegates..cctor() --- End of inner exception stack trace --- at Python.Runtime.Runtime.Delegates.get_PyGILState_Ensure() at Python.Runtime.Runtime.PyGILState_Ensure() at Python.Runtime.Py.GIL() at Python.Runtime.Loader.Initialize(IntPtr data, Int32 size) at Python.Runtime.Runtime.Delegates.get_PyGILState_Ensure() at Python.Runtime.Runtime.PyGILState_Ensure() at Python.Runtime.Py.GIL() at Python.Runtime.Loader.Initialize(IntPtr data, Int32 size)I am not sure how to properly make
netstandard2.0assembly to reference and copy those DLLs properly for running on 4.6.1, would appreciate some insight on what I am doing wrong.If this is reasonably solvable, will there be opposition to allowing 4.6.1 (with a strong recommendation to update to 4.7.2) potentially, if, say, I submit the PR fitting the requirements?
Also, outside of that, are there any blockers for going even lower theoretically (if I don't need to support anything else than .NET Framework)? Not as a part of the upstream/mainline.
- patched CLR Loader to compile for net461 (
I propose we drop support for the older .NET Framework versions, that do not support .NET Standard 2.0. According to the official documentation this would leave us with:
This should remove the
xplatoption, and a few polyfills as well as dependency on Python modules inside C# code in some cases (OS detection).@filmor @amos402 @benoithudson @BadSingleton