Can we have any clarification regarding usage of UnityEngine.dll vs using UnityEngine.CoreModule.dll (UnityEngine.AnimationModule.dll etc) in custom assemblies?
Unity 2017.2 update log states:
At some point, TextMeshPro switched to new UnityEngine.CoreModule.dll, and forced us to update all our dependency dlls that were referencing TextMeshPro to new split-style DLLs.
However, now TextMeshPro switched back to UnityEngine.dll, and now we have to rebuild our dependencies again. Besides, Unity 2017.3 editor crashes when attempting to load our dlls that reference new-style dlls (UnityEngine.CoreModule.dll).
Can we have a clear answer: what is the state of UnityEngine.dll and why was it split? Should we use new split-style dlls or stick to the old UnityEngine.dll? What is the future plan?
Referencing the split DLL by TextMesh Pro was a mistake on my part which I corrected in the latest release. Referencing the main UnityEngine.dll is the correct implementation.
@Stephen_B Also, is there a reason why you are renaming the assembly every time TMPro is released? There is an issue with backwards compatibility with asset bundles. Basically the guid is changing and the assembly names are different. It makes it very difficulty to build dlls against when things change drastically. We are forced to rebuild all of our asset bundles every time TMPro is updated.
Although the names of the DLL do change, the GUIDs and FileIDs are maintained between all those versions.
With respect to Asset Bundles, I am not / was not aware that using a different name on those DLLs could affect previously create bundles. I’ll reach out to the Asset Bundle team to get confirmation of this.
Now that I think about it, do you not have to rebuild bundles when you switch to a new version of Unity? I know that whenever serialization upgrades happen, this does require rebuilding Asset Bundles.
So in these case were you upgrading to a newer version of TMP while continuing to use the same version of Unity or does this happen when you upgrade both? Ie. This behavior could be the result of the Unity upgrade not TMP changing DLL names. Just looking for more information from you.
Backwards Compatible Bundles
When you upgrade Unity versions, you don’t necessarily have to rebuild bundles. It is all dependent on what is inside those bundles. We treat our prefabs as “views” and only add Unity based components (other components added at runtime). There was a serialization change in major Unity upgrade, but not between 2017.2 and 2017.3.
In short, bundles we built with 2017.2 had TMPro components. They are not being found once loaded in 2017.3 with the TMPro upgrade. So we need to rebuild them.
TMPro is the only component in question. All of our other components load as expected.
Unity Engine DLL Question
Can you confirm for us that we should only be using UnityEngine.dlls for referencing inside our libraries, or should we be preparing to move to the *.CoreModule, *.UIModule, etc dlls? Or are those for internal use?
I’ll get in touch with the Asset Bundle team and provide some feedback once I have information from them.
Independently from that, Unity 2018.1 will include the new Package Manager which will allow deployment of TextMesh Pro via this new tool. As such starting with Unity 2018.1.0b2, TextMesh Pro will be included with the Editor. This new version will include source code but use the new Assembly Definitions. This new version required that I use a new set of GUID’s and FileID’s but will include a Project Conversion Utility to convert from DLL version or Source Code version to this new one. Although you will have to again (sorry) rebuild those bundles, this will be the last time provide serialization or other factor outside of TMP require this again.
You should be referencing the main UnityEngine.dlls and not the individual ones.
This project includes simple asset bundle (built with TextMeshPro 2017.2 version) and a simple test script that loads that bundle and instantiates a canvas prefab that contains TextMeshPro text.
Here is how you can use this project to replicate:
Open the project
Click “Play”. Confirm that “TextMeshProUGUI” component is loaded and text is visible in the game view.
Switch TextMeshPro version by opening “project/Assets/Plugins” folder in Finder or Explorer and remove your “TextMeshPro_2017.2” folder. Remove dot (“.”) before “TextMeshPro_2017.3” folder, allowing Unity to load it. Switch back to Unity and wait for it to re-import new TextMeshPro assets.
Click “Play”. TextMeshPro component is now missing and “Referenced behavior is missing” error is shown in the console.
How does this work with externally built libraries? Our features are compiled into different dlls. For instance:
MyFeatureA.dll
MyFeatureB.dll
Each dll has different requirements, but one may be TextMeshPro. So if it is distributed via source-code and only compiled through asmdef, how will we be able to reference this? Please correct me if I’m wrong, but this seems like a regression in extensibility to unity itself.
The TextMesh Pro UPM (short for Unity Package Manager) package includes the source code. However, in the “Scripts/Runtime/…” folder it includes an .asmdef which tells Unity to compile the scripts in that folder into a separate assembly. This has the benefit of not having to recompile those scripts every time your own source code is changed. If that .asmdef file was to be deleted then these script would be compiled just like they have always been in the past.
In terms of how this gets handled in a final Unity project build, I am not entirely sure and as such would suggest you post / direct these questions at the scripting team. There was an Assembly Definition specific thread in the Beta 2017.3 forum section but that is now archived so I assume the Scripting section of the forum would be the place to ask.
We have traditional Visual Studio (non-unity source code) libraries that are compiled to dlls. We then import these dlls as our “features” into the Unity project. For instance: We have a library called “WebServices” which we compile and bring in as a precompiled dll into Unity.
We do this for other features as well, such as our UI for our game. We build our code into dll’s and distribute. In order to reference TMPro components, we need to reference a dll in our .csproj for our libraries. If TMPro is moved completely into UPM, where the code is compiled in the unity project itself, then how can any developer reference TMpro for external dll development?
Dynamic Link Libraries (dlls) are used to share features, functionalities, and frameworks across traditional .net development. For instance, I can use NuGet to include a package for JSON.Net.
Please correct me if I am wrong, but it sounds like there will no longer be “releases” of TMPro where we can reference a specific TMPro-Runtime.dll for our external development?
The Unity Package Manager (UPM) is just an alternative delivery mechanism for the package. Instead of downloading TextMesh Pro via the Asset Store and then importing TMP into your project, it will live in a Unity shared folder between all projects thus avoiding having multiple copies of the same package. Although these package will reside outside of your project, the package manager has the ability to access these just as if they were part of the project.
There are plans to make it possible for users to embed packages into their projects but I am not sure when that feature will become available.
In terms of the assemblies, in the Project/Library/ScriptAssemblies/…" you will find the “com.unity.textmeshpro.Runtime.dll” and the “com.unity.textmeshpro.Editor.dll” which are generated as a result of the .asmdef files located in the TMP folder that contains the runtime script and editor scripts.
UPM vs. Asset Store
For clarification: Are you saying this it will be available in both asset store and UPM? Or it will only be in UPM in the future?
Unfortunately, using the approach for taking dll’s out of the ScriptAssembiles, there would be no assurance that the File-Ids, GUIDs would be maintained between UnityProjects. This would prevent our multiple-products from using the same assets as we do currently.
Only UPM in the future is it will be included with the Unity Editor.
This new Assembly Definition feature ensures that GUIDs and FileIDs are maintained as when these assemblies are built, they rely on the .meta files of the scripts contained in the folder which includes the .asmdef file.
I’m sorry if this is not directly related to this thread, but how did you manage to only reference the main UnityEngine.dll
I have my own asset, when I compile it against multiple UnityEngine.*.dll I get this warning.
If I only reference UnityEngine.dll, say Unity_2017.3.1f1/Editor/Data/Managed/UnityEngine/UnityEngine.dll I get enormous errors like these.
Line number 4, Error Number: CS0234, 'The type or namespace name `EventSystems' does not exist in the namespace `UnityEngine'. Are you missing an assembly reference?
Line number 21, Error Number: CS0246, 'The type or namespace name `Text' could not be found. Are you missing an assembly reference?
Line number 26, Error Number: CS0246, 'The type or namespace name `PointerEventData' could not be found. Are you missing an assembly reference?
When I inspected the generated csproj by unity I actually found it referencing multiple UnityEngine.*.dll
OK, now I understood that the UnityEngine.module.dll are the ones to exclude, but UnityExtensions like UnityEngine.UI should be referenced. That fixed the above errors, but now I get those errors.
Line number 8, Error Number: CS1070, 'The type `UnityEngine.AudioClip' has been forwarded to an assembly that is not referenced. Consider adding a reference to assembly `UnityEngine.AudioModule, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
Line number 8, Error Number: CS1070, 'The type `UnityEngine.Object' has been forwarded to an assembly that is not referenced. Consider adding a reference to assembly `UnityEngine.CoreModule, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
Line number 8, Error Number: CS1070, 'The type `UnityEngine.Sprite' has been forwarded to an assembly that is not referenced. Consider adding a reference to assembly `UnityEngine.CoreModule, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
etc...
I’m using CSharpCodeProvider to compile by the way.
Edit:
I created an independent post for the topic.
Should the dlls built by the assembly definitions also be doing this as well? I noticed when I manually copied these dlls into my project they also carried this warning.
