Unable to reference Unity Package (specifically TextMesh Pro) from custom DLL

Hi everyone,

I have been searching the depths of forums and banging my head against the wall for 2 days over this hopefully simple issue. I have developed a custom DLL outside of Unity in its own csproj that depends on UnityEngine, UnityEngine.UI, UnityEditor, and TextMesh Pro. However, upon dropping the DLL into a Unity project to use, I get the error:

Assembly 'MyLibrary.dll' will not be loaded due to errors:

Unable to resolve reference 'TMPro'. Is the assembly missing or incompatible with the current platform?

What confuses me is

1. it has no trouble referencing UnityEngine, UnityEngine.UI, or UnityEditor. I know this because I built a version of my DLL that didn't include the components that referenced TMPro and it worked fine.
2. other scripts in the Unity project are able to access the TMPro namespace just fine.

I am on Unity 2018.3.6 with TextMeshPro 1.3.0 from the package manager. I am in a simple test project with nothing else going on, so it is easy for me to try anything.

Thanks in advanced!!!

 

Still not solved, but additional information has been posted in this thread: https://forum.unity.com/threads/una...esh-pro-unity-package-from-custom-dll.632200/

 

Custom dlls know nothing about unity packages. Try reference dlls from that custom package directly.

 

I find that very hard to believe. Surely there are plenty of people that would want to reference a Unity package from their own DLL? Especially something as common as TextMeshPro?

Could you elaborate? I'm not sure what you mean.

 

Unity scripting is based on .NET, not vice versa. Unity package is not something .NET assemblies are aware about. Custom DLL is just .net assembly and can reference other .net assemblies only. If scripts withing package are provided in form of a DLL or have assembly definition file, you may reference it from your custom .NET assembly.

 

Yes, but as far as i can see the TextMeshPro Unity package is just scripts with a few assembly definition files - nothing fundamentally different than scripts that would be in your assets folder. I'm beginning to wonder whether custom DLLs can't access scripts that have been put under an assembly definition file?

 

Whenever there's an assembly definition file in your assets, Unity builds an assembly. I think you could reference it directly.

 

Ahh right. I did actually try that, and that may be the general solution, but for TextMesh Pro that is not working. Referencing Unity.TextMeshPro.dll assembly under [UnityProject] -> Library -> ScriptAssemblies caused a dependency issue with UnityEngine.CoreModule, which doesn't make sense because referencing UnityEngine should reference UnityEngine.CoreModule.I provided more detail with screenshots in the post below:

https://forum.unity.com/threads/unable-to-reference-textmesh-pro-unity-package-from-custom-dll.632200/

 

This means you can't reference unity modules from .net assemblies at all. I suggest you write Unity script what takes commands from your external dll and passes them to the textmeshpro for workaround.

 

Gotcha. Could you provide an example of how to do that?

 

Code (CSharp):

1. class TextController : MonoBehaviour {
2.     private ExternalType _controller;
3.     private TextMeshPro _text;
4.  
5.     private void OnEnable() {
6.        _controller.onTextChanged += (newText) => _text.text = newText;
7.     }
8. }

This example is very basic and missing a lot of required stuff like unsubscribing a events and other. But you should get the idea.

 

I had the same question today and you CAN reference TextMesh Pro from your "custom" dll.
You just have to reference the correct dll, for example for TextMeshPro I had to reference the dll from YourUnityProject/Library/ScriptAssemblies/Unity.TextMeshPro.dll

After you added the (correct) TextMeshPro reference you can use all the classes with the TMPro namespace.

The "workaround" posted above works, but it's much easier to just reference TextMeshPro directly from your custom dll / project.

The folder also contains the dll for other packages, after you added them to your Unity project.

Also when you copy your "custom" dll(s) to your Unity project make sure that you don't copy any referenced Unity dlls into your Unity project again otherwise they would be duplicated and could cause errors.

For example in my VS project for the custom dll I changed the build output path of the dll to my Unity project, if you did the same then make sure that you set "Copy Local" to false on your referenced Unity dlls like TextMeshPro, otherwise they will also be copied to your Unity project.

 

This is temporary folder and should not be referenced. If you put your project under source control like git it wont build on others team members machines because that ref will be missing.

 

If a team works with custom dlls which reference Unity dlls then they most likely have to find a way to copy the needed dlls somehwere else, because they all have to reference the same version of the Unity dlls anyways. But there are many ways to manage these kind of situations.

Im just saying that you can reference and build the custom dll / Unity project successful if you use the dll from the folder. But you can also copy the dll(s) to a different location and reference it from there.

I don't work with a team but I still use source control and I usually create a "Unity dll" folder, copy all the dlls to this folder, reference them from there and add the folder to source control with the "custom dll project", so the path will always be the same and the project can be checked out and built from any pc.

 

Then you forced to update that dll at that location everytime it source updated because unity recompiles dlls it that temporary folder automatically.

 

That's true, but the recompiled TextMeshPro dll(s) will only be different if you change the TextMeshPro package version.
If you change the package version then you also have to reference the new dll, but you only have to do this once per version change.

It's the same process if you change Unity version, then you also have to reference the UnityEngine.dlls of the new Unity version, so I assume that the people who work in a team with source control and built custom dlls (which reference Unity dlls) already have a workflow for these kind of situations.