Mono 2.0 subset, precompiled .NET dlls, and TypeLoadExceptions

Questions & Answers
1

Within our Unity projects we are using a collection of .NET assemblies that are compiled from our source code within VS2010. Ideally we would compile these assemblies against the supplied Unity/Mono .NET subset core assemblies within Unity, but VS does not allow this, so they are compiled against the standard .NET 3.5 assemblies.

We only want to use the 2.0 subset option for Unity Windows, as we want to make it cross compatible with Web, iPhone, Android, etc.

If a script references a type within these assemblies, that in turn directly references a system type not available in the Mono 2.0 subset assemblies, a compile error is raised within the Unity editor.

However, more indirect references (script -> assembly A -> assembly B -> standard .NET type not available in subset) works within the editor! Adding some logging I noticed it is resolving the type from the full Mono directory (\Mono\lib\mono\2.0), rather than the subset directory (\Mono\lib\mono\unity).

This obviously fails once the project has been deployed and run externally to the editor. Additionally, reflecting over one of these assemblies will cause similar issues on the deployed version, but not within the editor.

So firstly, you may have a possible bug in the compiler and/or type/reference resolving. Secondly, it is rather tedious trying to work out what is and isn't available by deploying, looking at the log, and seeing a general 'System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded' exception. Could Unity3D staff possibly provide me with documentation of what is available in the 2.0 subset build option? Or if someone has a better idea of how to approach this task, it would be greatly appreciated.

2

Unity has several different classlib "profiles". We have "2.0" "unity" and "unity_web". We compile your sourcecode against the profile you selected in the playersettings.

The editor itself is built against 2.0, and due to technical reasons, that means your gamecode, while compiled against the right profile, will run against 2.0. (which is a superset of all other profiles, which is why this works).

Since you compile your assembly in visualstudio, visualstudio can compile against the full 2.0 profile, and it is indeed misleading that such an assembly in the editor actually works, but will fail to build. It would be nicer if we could warn about this earlier.

It is also unfortunate that visual studio does not allow you to compile against a "custom" class library profile. It only lets you compile against the "official" .net2.0, .net3.5 etc classlibs. Unity ships custom class lib profiles, because a lot of the classlib stuff does not make much sense for most games, while it can in some cases add to your filesize.

I don't have a great out of the box solution for you, however, what you could do to smooth your workflow is add a postbuild step to your visualstudio build, that verifies if your generated assembly is referencing any types that do not exist in the "unity" profile. You could write a small program that does this ontop of Mono.Cecil

In the upcomgin Unity3.2 release, we have more detailed information about which types are and are not available in each different profile. Untill that time, you can use a tool like .net reflector to inspect our mscorlib.dll & system.dll & friends to figure out what exactly you are referencing that does not exist.

3

Here is the more detailed information Lucas mentions in the answer above:

http://docs.unity3d.com/412/Documentation/ScriptReference/index.Unity_and_Mono_compatibility.html