Any way to force .net 4.6.1? 4.7.1 unavailable for OS

Unity Engine
1

Since scripting runtime .net 3.5 is being deprecated, I’ve tried switching to 4.x in the beta, but it seems to jump to using 4.7.1 without any middleground.

When visual studio is launched, it asks to convert to 4.6.1 each time since the 4.7.1 targeting pack isn’t installed.
I cannot currently install any higher because my OS version doesn’t support it.

I can still use VS to edit scripts, but tracking down errors is tricky without direct integration. (Unity is complaining it can’t find Microsoft.Win32.Registry after switching to 4.x, but VS intellisense shows it just fine for example)

Is there any way to get unity to use 4.6.1 specifically instead of the generic 4.x profile?

I understand upgrading my OS is one solution, but it’d be a shame if this was the first thing that flat out didn’t work on my current one due to such a minor difference.

2

We don’t have a way to change the target framework version in the .csproj file that Unity generates now, but we are working on a solution for this issue. Which OS are you using that you cannot install .NET 4.7.1?

3

A pre-anniversary update windows 10. Particularly annoying that .net 4.7.1 works for Win7 SP1 from 2011 but not a windows 10 install from 2015.
Mono 5.10 that supports .net 4.7.1 installs just fine by comparison.

Okay, thanks - I’ll go back to 3.5 for now and hope something gets worked out before it gets fully removed.

I know I’m quite silly/stubborn about not updating in so long, but at this point it’ll be a knock-on effect that’ll cause a whole bunch more conflicts than it’ll solve heh.

4

When you use JetBrains Rider, its EditorPlugin has an option to manually override TargetFrameworkVersion.

5

With Visual Studio Tools for Unity, you can also fully control the csproj being generated.

Add an editor script like this in your project:

Regards
Sebastien Lebreton [MSFT]

1 Like
6

Thanks! With that as a base, I found/modified something similar and got it working.
Here’s the result for if anyone in the future has similar problems:

vsproj framework replacer code

using System.IO;
using System.Linq;
using System.Text;
using System.Xml.Linq;

using UnityEditor;

//#if ENABLE_VSTU //not defined in VS for me for some reason
using SyntaxTree.VisualStudio.Unity.Bridge;

[InitializeOnLoad]
public class ProjectFileHook
{
    private const string SCHEMA = @"http://schemas.microsoft.com/developer/msbuild/2003";
    private const string ASSEMBLY_NAME = "AssemblyName";//XML category for assembly
    private const string ASSEMBLY_CSHARP_RUNTIME = "Assembly-CSharp";//value for assembly name
    private const string TARGET_FRAMEWORK_VERSION = "TargetFrameworkVersion";//XML category for .net framework
    private const string FRAMEWORK_EXPECTED = "v4.7.1";//old value for framework
    private const string FRAMEWORK_DESIRED = "v4.6.1";//new value for framework
   
    class Utf8StringWriter : StringWriter
    {//to allow UTF8 saving
        public override Encoding Encoding
        {
            get { return Encoding.UTF8; }
        }
    }

    static ProjectFileHook()
    {
        ProjectFilesGenerator.ProjectFileGeneration += (string name, string content) =>
        {
            var document = XDocument.Parse(content);
            var assemblyName = document.Descendants(XName.Get(ASSEMBLY_NAME, SCHEMA)).FirstOrDefault();
            if( null != assemblyName && assemblyName.Value.Contains(ASSEMBLY_CSHARP_RUNTIME) )
            {
                var target = document.Descendants(XName.Get(TARGET_FRAMEWORK_VERSION, SCHEMA)).FirstOrDefault();
                if( null != target && target.Value.Contains(FRAMEWORK_EXPECTED) )
                {
                    target.SetValue(FRAMEWORK_DESIRED);
                }
            }
            var str = new Utf8StringWriter();
            document.Save(str);

            return str.ToString();
        };
    }
}
//#endif

With that working, I managed to use a nuget asset to get microsoft.win32.registry.dll included (though had to fiddle a lot with the dll import settings) and it all compiles!
Hopefully there’ll be support for not overwriting nuget stuff added by VS in the future, since some of the more specialized references aren’t there directly anymore when using 2.0 standard if I understand it right.
Would be a lot less hastle letting VS manage it all and tell unity about each DLL automatically than having to use a clone of the same functionality within unity.