Managed DLL configuration

Hi,

We've just discovered a problem with the import of managed DLL across multiple platforms.
Before filing a bug report, I wanted to know what is expected behavior and what is not.

So, in our situation, we have a DLL developed with Visual Studio 2017 on Windows, targeting .Net 4.6.
The project is configured with .Net 4.6 for now, I will test later to check if the problem also happens with .Net 3.5. [UPDATE] The bug also occurs when using .Net 3.5

We have two DLLs representing the same assembly, one is configured to only be used in the editor, the other to only be used in builds. All configuration is done via the inspector and works as expected. I have not tested yet if the bug appears with a single DLL [UPDATE] It does.

The main problem is :

When loading the project on a MacOS machine, the DLL configurations are not taken into account, they both are configured with the default settings (resulting in a failed compilation).
If we change the configuration to match the original one, everything now works as intended despite no change in the corresponding meta files !

Weirdly enough, deleting the "Library" folder and reloading the project does not make the bug reappear.
This indicate Unity stores some sort of data outside of the "Library" folder which, to my knowledge, usually holds all cached information.

Deleting the whole project folder and reloading it again makes the bug reappear though.

Side question :

What is the expected behavior when using Monobehaviour and ScriptableObject classes in a managed DLL ?

So far, in our testing, we've seen some weird inconsistencies :

• On the windows machine where the DLL is developed, instances of a scriptable object class defined in the DLL always keeps its link to the script. Even if the "Library" folder is deleted.
• When importing the project on the MacOS machine, even after fixing the DLL configuration, the instances are broken (the corresponding script GUID has changed).

So the question is : is this supposed to work or is it mandatory to create some sort of wrapper outside of the DLL directly in the assets ?
The documentation about this subject is lacking and only mentioned the possibility to have Monobehaviour classes inside the DLL.

Thanks in advance to anyone who can give some sort of answer to this

 

Hey Leonhard,

Thanks for your answer.

After some hours of trying to figure out what was exactly happening in order to make a bug report, I think it's linked to the non installation of some build targets when installing Unity.
To summarize, when a build target is not installed, the assembly gets mis-configured in some way for those build targets.
When importing a project containing such assembly on one of those platform, the assembly is not correctly configured and is not correctly imported.
Moreover, the assembly inspector sometimes throws some errors preventing the correct reconfiguration.

I described it with more detail in the bug report, I hope it'll help, it was somewhat tricky to explain and I'm not sure I precisely pinpointed the actual problem.

Anyway, the bug case is #918721