Linking Unity 2022 UnityEngine.dll and UnityEditor.dll from .Net 3.5

Unity Engine
1

In attempting to update Rewired for Unity 2022, I discovered that Unity is now building all engine DLLs to Net Standard 2.1. UnityEngine.dll and UnityEditor.dll (and others) are now Net Standard 2.1 libraries, which makes it impossible to link to them from a .Net 3.5 DLL project (all Rewired projects on all platforms are .Net 3.5, apart from the platforms that never supported 3.5). So the obvious answer is to remake all DLL projects as Net Standard 2.1 projects for Unity 2022. However, I see that Unity also still has support for the API compatibility level setting of .NET Framework. Including a Net Standard 2.1 DLL in a project set to .Net Framework compatibility doesn’t sound right. Will that even work?

The same problem exists for UnityEngine.UI.dll. When API compatibility level is set to .NET Framework, Unity builds a UnityEngine.UI.dll that is built for .NET Framework 4.0. When API compatibility is set to Net Standard 2.1, it builds a DLL for Net Standard 2.1. Because Rewired_Core.dll references UnityEngine.UI.dll, it has to be compatible with the DLL project’s framework in order to reference it to build the DLL. This has been a problem for a while since Unity dropped .Net 3.5 support a long time ago for Unity UI (Unity doesn’t include a .Net 3.5 DLL, nor can it build one), but I was able to rebuild my own .Net 3.5 UnityEngine.UI.dll using the code from the Unity UI package and reference that from my DLL so it would build However, I cannot do the same for UnityEngine.dll or UnityEditor.dll because I do not have the source code for those.

While it does work to continue to build .Net 3.5 DLLs that reference the UnityEngine.dll and UnityEditor.dll from Unity 2021, this is obviously not correct and will definitely break in the future. It also makes it impossible to remove calls to deprecated code in the DLL.

I must be able to build DLLs that:

  • Reference UnityEngine.dll
  • Reference UnityEditor.dll
  • Reference UnityEngine.UI.dll
  • Can be included and built in a project set to .Net Framework API compatibility.
  • Can be included and built in a project set to Net Standard 2.1 API compatibility.

Does anyone at Unity have any suggestions on how to deal with this new issue?

2

So, .net framework compatibility level is still here, but it is a special one:
It does not actually build against .net framework, but against the Mono profile used in Unity (that is based on .net fx 4.8 + everything needed to implement .net standard 2.1).

A project built with this profile can actually reference any .net standard 2.1.

Our advice for 3rd party assemblies, is thus to build on .net standard 2.1 (and if it is missing things from .net fx, you can also reference the .net framework compat shim - as it is implemented by Unity mono runtime as well).

1 Like
3

Thanks for the information. I will proceed with Net Standard 2.1 then and hope everything works.