The process of importing DLL's between Unity 4 and Unity 5 is slower.


  • Importing a DLL in Unity 5 is in the order of 5-10 times slower than in Unity 4.

The assemblies need to be updated by AssemblyUpdater. (With the introduction of Unity 5.0 the upgrade process is automated with AssemblyUpdater and ScriptUpdater).

With Unity 5.x a new .Net attribute (UnityAPICompatibilityVersionAttribute) was introduced. This can be applied to assemblies to declare that they only use APIs that are compatible with a specific Unity version. When the assembly updating tool runs, it checks the assembly being processed for this attribute. It assumes the assembly does not need to be updated if the version in the attribute matches the current Unity version (Application.unityVersion).

With this change, a line like the following can be added:
[assembly: UnityEngine.UnityAPICompatibilityVersion("1.2.3f1")] // in C# and Boo
@assembly: UnityEngine.UnityAPICompatibilityVersion("1.2.3f1") // in UnityScript

The updater will not bother to check the assembly containing this code when it gets imported into Unity (if Unity has the same version, i.e, 1.2.3f1).

More Information 

This article applies to Unity versions 5.0+

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request


  • 0

    Please consider a way to disable the AssemblyUpdater via e.g. meta file:

    * We have numerous plugin DLLs that we regularly compile, but don't want a reference to UnityEngine in, so have no way of adding the assembly attribute.

    * Even for DLLs with UnityEngine references we consciously upgrade unity versions, in the whole team, and can (and want to) maintain API compatibility ourselves.

    It's a great too for DLLs without source code, but it can really slow things down with our workflow.

  • 0
    Jordi Bonastre

    Feel free to post your suggestion in, there isn't anything similar.

Please sign in to leave a comment.