Unity 2018: .Net version mismatch in generated c# project files

Unity Engine
1

I’m trying to migrate to Unity 2018 and hit an issue.

The problem is that the project files, generated by the editor, reference mono 4.7.1 dlls, but the target framework of the project itself is 4.6. In my view, it looks like a bug.

My specific issue is as follwing. I use an external solution, that builds some dlls into the Unity asset folder (to share logic with the server, and to be able to use C# 7). I also use tuples extensivly and there lies the problem. Since the generated projects target 4.6, I have to target it in my external solution too. This version of .Net doesn’t include ValueTuples, and so I have to include them via nuget. But the generated Unity projects reference mscorlib 4.7.1, so they won’t compile due to ambiguous class reference error.

This wouldn’t be an issue if the generated projects referenced and targeted the same version of .net, either 4.6 or 4.7.1.

Is there any chance it could be fixed? Or maybe someone knows a workaround?

2

I’m guessing this is where your problem lies.

You’re going to have to ditch it. Or find an experimental solution with low lifetime.

3

Thanks fo the reply!

Unfortunately, this actually has nothing to do with C# 7. I can use C# 6 and the problem still persists. Moving the .cs files from a separate solution to Unity assets would solve the problem, though, but I want to keep them separate, since I share some data and logic with the server code. Rewriting the codebase to not use tuples would work too, but will take a lot of time.

The issue here is with this lines in the auto-generated Assembly-CSharp.csproj:
…
v4.6
…

C:/Program Files/Unity2018.1.1/Editor/Data/MonoBleedingEdge/lib/mono/4.7.1-api/mscorlib.dll

…

Basically the compiler is told to target framework 4.6, but uses dlls from 4.7.1. This isn’t an issue in 2017.4 by the way.

For now looks like my choice is to either use 2017.4 and target .net 4.6 or to use 2018.1 and target .net 3.5. Any ideas?