Thanks for trying out the new build with these libraries, we really appreciate it!
We have discussed this some, but we don’t have a good plan for how to handle it yet. There is some independent work by other teams at Unity on a better general package management system. I think that we might be able to work with nuget and that future feature if/when it is ready. But this is all very early to have any certainty.
For now, we’re left with manually copying assemblies into the Unity project.
I believe there’s a bug somewhere that reverts API Compatibility Level back to “Mono 2.0” even though “.Net 4.6” is the only value that is allowed in this preview build.
A couple of times the compiler stopped compiling my code that relies on .Net 4+ features, just as if I were targeting .Net 3.5. The last time it happened I checked the editor log and saw that the .rsp file, that is generated for the compiler, ended with
Then I went to the Player Settings to check the current API Compatibility Level, and at the moment I opened these settings in the inspector window, the editor launched the recompilation and it succeeded. Then I checked the editor log again and the recent .rsp file there ended with
Thanks for reporting this. It sounds like an ugly one to track down. We will have a look to see if we can find the culprit. If you notice this again, please let us know.
I have a problem with the use of System.Lazy<Interfaces.IAvatarsController> and other system Lazy it show us:
Error CS0433 the type “Lazy” is in “nunit.framework, Version=3.6.0.0, Culture=neutral, PublicKeyToken=2638cd05610744eb” and “mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089”. Assembly-CSharp C:\test_projects\Service Client Test\Assets\ServiceClient.cs 30 Aktiv
which is actually without importing mscorlib or nunit.framework.
Same is for Error HttpClientHandler CS0433 the type “HttpClientHandler” is in “System.Net.Http, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” and"System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" . Assembly-CSharp C:\test_projects\Service Client Test\Assets\ServiceClient.cs 14317 Aktiv
But here it happens after import System.Net.Http via Nuget config directly into the acces folder. Before I import System.Net.Http it says that it couldnt be found. So because of the way of import i am not sure if I causing the Problem for System.Net.Http by myself.
Btw. Newtonsoft Json seems to work fine after Nuget import. At least the first trys.
I don’t know of a work around for these issues. Would you mind submitting a bug report (or two) with these projects? It seems there is some sort of conflict that we should investigate.
Yes, I observe the same behaviour. After opening a project it looks as if compiler is set to compile with old .NET profile, thus generating a lot of errors. Then when I open the Player Settings to check the API level, it starts recompiling the project and the errors go away.
Sadly, this issue doesn’t allow me to build the project on our build server from command line using batchmode. I can still build it from the Editor on my own machine, though.
I tried to create a new repro project, but for some reason it works just fine there.
Is it possible for you to provide the original project that causes this issue in a bug report? I wonder if there is something related to an upgrade from an existing project that causes this issue.
Unfortunately it’s against our company’s policy. Besides, it’s really huge. Our project folder is currently about 65 Gb.
I think I’ll try to strip down the project until I get minimal repro case and then report it.
Okay, this won’t be necessary. I think I found the culprit. It’s because of the ProjectSettings.asset file.
It seems when I open the Player Settings tab, Unity switches the API level and changes this line:
apiCompatibilityLevelPerPlatform: {}
to
apiCompatibilityLevelPerPlatform:
Standalone: 3
And if I save the project, everything works fine afterwards. But since our build machine was checking out the latest commit from git, it was reverting the file back every time. Committing ProjectSettings solved the problem.
It looks like the bug is indeed related to the project upgrade from previous versions of Unity.
Create a new project in the Mono Upgrade Preview build, put some script that uses Net 4+ features. For example,
using System.Linq;
using System.Runtime.CompilerServices;
using System.Threading.Tasks;
using UnityEngine;
public class Test
{
[MethodImpl(MethodImplOptions.AggressiveInlining)]
private void SomeMethod()
{
Task.Factory.StartNew(() =>
{
var ints = Enumerable.Range(0, 100);
Parallel.ForEach(ints, i => Debug.Log(i));
});
}
}
Reopen this project in Unity 5.6 beta. Open the player settings at least once and save the project.
Reopen the project again in Mono Upgrade Preview build and see the compilation error that “type or namespace Task doesn’t exist”.
Open the player settings and see how the error disappears during automatic recompilation.
Repeat steps from 2 to 4 until satisfied.
Earlier I said that I had run into this problem a couple of times. Now, when I think about it, it’s very probable that I opened the same project several times both in 5.6 beta and Mono Upgrade Preview build.
This one can be fixed easily. Open your Unity installation and copy nunit.framework.dll from
to
replacing the existing one.
The second one targets CLR 2.0, which makes sense for regular Unity builds. However, it contains duplicates of several types from CLR 4.0 and for some unknown reason these duplicates are made public.
Picture
Are you planning on releasing preview builds more frequently now? Unity 5.6 beta 5 has this annoying bug where Unity crashes every half hour or so and it’s ruining all the fun I’m having with with the tasks library
I was not aware of that bug! We have now been able to get the managed code debugger to work internally, so I suspect we will do another build soon with that plus other fixes.
We’re not ready to commit to a regular cadence yet though.
@JoshPeterson I know we ask for a lot, but, what about a build based on 5.5? Or is there a technical reason for basing it on the 5.6 beta? It’s hard to tell which bugs might be due to the beta and which might be due to the Mono upgrade.
