Update Unity DLL to target .NET 4.5?

[bliu886]

With the Unity 2018.1 release in early May, Unity now officially supports .NET 4.5. can the Unity DLLs be rebuilt to utilize .NET 4.5? The current Unity DLLs target 3.5 and I would like to use the .NET 4.5 features.

[JonMcPherson]

👍 +1

[TobiasPott]

Hello @bliu886 & @JonMcPherson ,

it's been a while that you've posted this request to update the assemblies target framework to 4.5. Since then @TheFanatr did a upgrade of the main repository to .NET Standard, with this upgrade the old structure of target platform assemblies was removed in a first step and might return in a new form sometime in the future. You will either need to do the target framework update yourself on an old commit, wait for the platform specific plugin to return or stick to my current approach to make the parseSDK for .NET work with Unity (see below).

This said, you might check out https://github.com/TobiasPott/Parse-SDK-dotNET/tree/feature/recode-unity-support which is a fork of the community repository which is based on the main branch but contains compile flags to allow usage in Unity (runtime and editor-time). This is not a fully tested repository, thus you should elaborate if it fit's your needs and works within your project.

Kind Regards Tobias

Edit: corrected link to point to actual feature branch containing Unity specific sources instead of master branch.

[Romaleks360]

Hello @TobiasPott Why can't I just use the master branch? It won't work with Unity?

[TheFanatr]

The master branch has not been updated to support Unity yet. I have not had any time to do this recently, but as soon as I do, I will try my best to progress on this front.

[Romaleks360]

Oh, I see... Can I use the 1.7.0 version from the releases? Or it's outdated?

[Romaleks360]

What's the difference between recode-unity-support and 1.7.0 except for the lack of notifications?

[TheFanatr]

You can use 1.7.0 and it will likely work correctly except that you will need to use the older scripting runtime. The recode-unity-support branch, as far as I know, is simply a partial rewrite of master that can be compiled for specific use in Unity as one assembly. For that version you will not have to use the previous scripting runtime.

[TheFanatr]

The title of this post implies that the previous runtime was in use anyways unless the preview feature of using .NET Standard was specifically enabled in a previous version of Unity, as the first version of .NET Framework supporting referencing assemblies which target .NET Standard 2.0 was 4.6.1, as can be seen here. Basically what this means is that if you are targeting .NET 4.5, unless you specifically enabled the feature in Unity, you cannot target .NET Standard 2.0 assemblies, which I think makes the only option 1.7.0, unless the recode-unity-support branch does not target .NET Standard 2.0. I may be wrong about this because Unity could be employing some tricks that would allow .NET Framework 4.5 assemblies to reference such .NET Standard assemblies, but I am not sure.

To summarize, use 1.7.0 for now if you're sticking to .NET Framework 4.5.

[TobiasPott]

@TheFanatr is correct about the recode-unity-support branch, it is the current master branch of this parse-community repository with changes made to allow direct usage within Unity.

I cannot make a clear statement about the differences between the recode-unity-support branch and 1.7 feature-wise as I cannot tell what is different from 1.7 and the current master branch, but compared to the master branch there are none I know of right now. Compared to 1.7 notifications are one thing, that is right.

I'm currently using the assembly from the recode-unity-support branch in a project using API compat level set to ".NET Standard 2.0" (and of course scripting runtime version ".NET 4.x equivalent". It is not that easy for me to tell if that applies to all Unity3D with some sort of .NET 4.x support but it does for sure do for the 2018 cycle.

Unity is not pinned to .NET 4.5 specifically but allows newer features too (that's why they label it 4.x I assume). I can't recall if they put it into the release notes which level is actually supported by a specific Unity version. When loading the .NET Standard 2.0 assemblies into Unity they are recognised as targeting 4.x and perhabs some magic is applied to them behind the scenes. The same assembly compiled from the recode-unity-support branch is usable with ".NET Standard" or ".NET 4.x" compat level set in Unity. At least it is when targeting Windows standalone, iOS or Android (cannot tell how strict they are when it comes to UWP or other platforms).

(If you have the time to evaluate the recode-unity-support branch I'll appreciate any feedback on it and potential missing parts or bugs)

[Romaleks360]

1.7.0 version gives a "MissingMethodException: bool UnityEngine.Application.get_isWebPlayer()" on start. I'm using 2018.2 version of Unity. 1.7.0 references some deprecated methods, so I have no other option but to use your experimental branch. (of course, I can change the source code and recompile but I'm afraid I'll have much more headache with it in the future) I'll let you know if I run into some problems.

Also, what's the current problem with notifications? Can we do something about it?

[TobiasPott]

The latest version supports the use in Unity and other platforms which behave slightly different then a standard .NET application. These may require additional configuration, see the use-in-unity-client section for an example mutators to be used within Unity. Due to the problems most likely solved, I close this issue.

If you encounter any problem feel free to create a new issue to discuss possible solutions.