Repository navigation
2018.1 with .NET 4.5+ is broken #824
Description
Activity
- changed the title
[-]Add .NET 4.5+ Support[/-][+]2018.1 with .NET 4.5+ is broken[/+]on Jun 12, 2018 Yup, this is definitely a problem, and I don't see a way around it without a separate build and a separate package just for the 4.6 runtime. Unity doesn't have per-.net-profile loading of assemblies, which makes this harder (I'd just ship a separate build if they did and load accordingly).
Your branch is still useful, we're going to have to do that work that you did, so I'd love a PR of that. All of the changes will likely need to be conditional (the csproj target framework conditional of a property and the code changes inside a #if NET_45 block), but otherwise it's fine (we can add those conditionals if you're not wanting to hack more on that branch, let us know).
So the plan is to generate two targeted builds per release?
At my fork was just to see if it will work so there's no backward compatibility, I just removed nuget references for asyncbridge, etc. manually changed the target .net framework and changed the only code bit change was some methods that was available as extensions (TaskEx.FromResult for example) are now directly in the Task, however it's possible to create a conditional wrapper.
Can nuget only include a package for a specific framework version?
I'll only be able to tinker with this at the weekends.
So the plan is to generate two targeted builds per release?
Yeah. The problem is that we have to build 3.5 assemblies in order to load in the non-4.6 Unity profile, and those assemblies won't be able to just use the new
System.Threading.Tasksbits that Unity has in the 4.6 profile, the types don't quite match. They'll work fine as-is, but any code that tries to use the new threading types will fail to compile. So, we'll have to build two versions ofGitHub.Unity.dllandGitHub.Api.dll, one for .net 3.5 and one for .net 4.6, I don't see any other way around it. We can do both builds from the same csproj files by adding a flag that we can pass in when building on the command line (and/or also as a solution configuration), that's not a problem.Unfortunately, there's no way to tell Unity to conditionally load assemblies based on their target profile right now, so we can't put both builds in the same package, Unity would try to load all of them, which means we'll need separate packages (sigh).
The PR is there, let me know what you think about it.
Thanks
Hey @capyvara there was a beta build put up a few days ago. I dunno if you saw it.
Let me know if it solves the issue for you.I'll try this week
Prerequisites
Description
Since Unity 2017 the .NET 4.X is available as experimental, on Unity 2018 it became fully supported: https://blogs.unity3d.com/2018/03/28/updated-scripting-runtime-in-unity-2018-1-what-does-the-future-hold/
However when you enable it inside Unity, it conflicts with the AsyncBridge related dependencies (TaskParallelLibrary, etc), showing errors that some classes already been defined in another assembly, since these classes are now present in the mscorlib.
Steps to Reproduce
Additional Information
I've "fixed" this in a branch at my fork:
https://github.com/capyvara/Unity/tree/enhancements/dotnet-4.x
However I haven't submitted a PR since probably you're looking in supporting both .NET versions and I'm not sure how to better handle this.