Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. Voting for the Unity Awards are OPEN! We’re looking to celebrate creators across games, industry, film, and many more categories. Cast your vote now for all categories
    Dismiss Notice
  3. Dismiss Notice

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

Discussion in 'Scripting' started by degorov86, May 22, 2018.

  1. degorov86

    degorov86

    Joined:
    Nov 20, 2017
    Posts:
    2
    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. FMark92

    FMark92

    Joined:
    May 18, 2017
    Posts:
    1,244
    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. degorov86

    degorov86

    Joined:
    Nov 20, 2017
    Posts:
    2
    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:
    ...
    <TargetFrameworkVersion>v4.6</TargetFrameworkVersion>
    ...
    <Reference Include="mscorlib">
    <HintPath>C:/Program Files/Unity2018.1.1/Editor/Data/MonoBleedingEdge/lib/mono/4.7.1-api/mscorlib.dll</HintPath>​
    </Reference>
    ...

    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?