Referencing 3rd party Scripts from External Assemblies

All my non-MonoBehaviour classes are developed in VS outside of unity and then transferred as a .dll to my Assets folder. My MonoBehaviours are in script (source) form in the Asset folder. I also have other scripts in the Asset folder purchased through the Asset Store. Some of my std classes in my external .dll need to have access to the Asset Store acquired scripts. To do this in VS, I’ve added the 3rd party source code as a project and referenced it successfully from my VS project, allowing me to reference those scripts. So far so good.

Here’s the rub: When I compile my Std classes into .dlls and copy over to Unity, a .dll for the 3rd party project is also created and dragged along as it is referenced in my .dll. Having the VS-generated, 3rd party .dll in Unity in support of my std .dll results in a conflict with the 3rd party scripts already there. Deleting the 3rd party .dll in Unity results in my .dll not finding the 3rd party references it needs in Unity even though the 3rd party scripts are there.

I’ve tried simply referencing the Unity Project C# .dll from my VS project which should contain the compiled 3rd party source, but the 3rd party code doesn’t appear to be there.

In my observation, this appears to be a general problem with Asset Store scripts that need to be referenced from within external .dlls. I’ve searched all the forums and can’t even find the subject as an issue, much less a workaround. What am I missing and can anyone point me in the right direction?

The correct solution turned out to be referencing the 3rd party .dll built by Unity, but, it turned out that .dll was the plugin (first pass) assembly, not the main assembly. That is why the 3rd party code didn’t show up when I initially referenced the assembly.

I was having the same issue you described when deleting a DLL duplicate.

Like all other assets, DLL processing happens when you first import the file or start up Unity. I assume in the case that theres a duplicate being imported, the editor “overwrites” the location of a DLL when one with the same file name and namespace is created. Then when you delete the duplicate DLL file, it doesn’t attempt to search and link the prior DLL, because there’s no history tracking; it has no reason to. So, it just appears as a missing reference.

There’s probably two ways to go about it: either you find some VS build commands so that it doesn’t duplicate the dependency DLL, or delete the duplicate from your file/asset explorer and restart the editor. When the editor restarts, it should search the files and link the original 3rd party DLL, because that’s the only copy it has now.