Resolved Imported DLL to call Unity project function

Hello,

Ive got a precompiled DLL that i import into Unity. In Unity, i can then instantiate objects, using the new classes, that are compiled inside that DLL. All good.

Next, i wanted to read a property of say.. a static class (so a static public property) - but call it from that DLL, but when that static class resides in the Unity project. So to call that directly, i needed to know it's Type. So i called

Code (csharp):

1.  
2. Type.GetType("UnityProjectClassStatic");
3.  

...but i get a null. Wait.. so .. then i test GetType from inside Unity project (some MonoBehavior attached to some display object.. and i get a proper type [UnityProjectClassStatic] - weird - i think - so the DLL doesnt have access to types, which are not local to that DLL? Is this something to do with the Assembly boundary?

I do some more tests.. this called from within the DLL, tries to get Types of classes that are declared inside the Untiy project:

Code (csharp):

1.  
2.             Debug.Log("1) type="+Type.GetType("UnityProjectClass"));
3.             Debug.Log("2) type="+Type.GetType("UnityProjectClassStatic"));
4.             Debug.Log("3) type="+Type.GetType("UnityProjectMonoBehaviour"));
5.  

First check checks for a non-static class type, present in Assets/Scripts/UnityProjectClass.cs
Second check is another class, same case, just a static class
Third Check is a 'extends MonoBehaviour' class attached to a GameObject in the loaded scene

All checks are null.

When i run the same code on a script/function that resides inside the unity project (not a DLL) (with [RuntimeInitializeOnLoadMethodAttribute])... then..

All checks trace proper types (no nulls)

Also, the function inside UnityProject with said attached attribute executes prior to the function with the same attribute inside the DLL - which makes me think that this is not a Script Execution Order issue. I also see getType accepts an 'assemblyResolver' parameter - but i think this is used the other way around - when using Reflection to call DLL functions from within the Unity project?

One more test from inside the DLL: following code:

Code (csharp):

1.  
2. UnityEngine.Object[] results = Resources.FindObjectsOfTypeAll<MonoBehaviour>();
3. foreach (UnityEngine.Object result in results) {
4.    Debug.Log("result: "+result+" type: "+result.GetType()+" UnityProjectMonoBehaviour: "+(result.GetType().ToString() == "UnityProjectMonoBehaviour"));
5. }
6.  

Among other results it returns:
result: MyGameObject (UnityProjectMonoBehaviour) type: UnityProjectMonoBehaviour UnityProjectMonoBehaviourr: True

The value can then be traced using Reflection:

Code (csharp):

1.  
2. public static object GetPropertyValue(object source, string propertyName)
3. {
4.     PropertyInfo property= source.GetType().GetProperty(propertyName);
5.     return property.GetValue(source, null);
6. }
7. Debug.Log(GetPropertyValue(result, "myProperty").ToString());
8.  

To conclude:
Resources.FindObjectsOfTypeAll (and maybe other similar utility methods) do find the object with said class. But why does the DLL not know the type, when loaded into Unity?

TLDR: Is there a way for a compiled DLL imported inside the Unity project to access classes/objects/methods inside the Unity project by their Type (directly)? Im mostly interested to be albe to access a public property of static class that resides in Unity project from a precompiled DLL inserted within the same project.

 

You're almost certainly going to need to use the qualified assembly name since it's coming from a different assembly. Also, any reason you can't use typeof() in the first place?

https://docs.microsoft.com/en-us/dotnet/api/system.type.gettype?view=net-5.0
https://docs.microsoft.com/en-us/do...iew=net-5.0#System_Type_AssemblyQualifiedName

 

As GroZZler said, you would need the assembly qualified name of the class. Assemblies can not have circular references. All your scripts inside your project are compiled into an assembly. Any precompiled assembly you import into Unity will be referenced by the compiler when the scripts assembly is compiled. However when you compiled your own assembly, you can not reference the scripting assembly as well. So the assembly qualified should look something like this:

Code (CSharp):

1. Type.GetType("UnityProjectClass, Assembly-CSharp.dll"));

assuming the class you're looking for is in the normal compilation group and not in any other assembly. Note that

Type.GetType

does not necessarily be able to find internal or private classes. A more reliable way is to enumerate all loaded assemblies of the AppDomain and use the GetTypes method on each assembly to get an array of all types defined in that assembly. For reference have a look at the code I posted over here.

 

OMG whats that perk
i cant find it!

Thanks for the 2 links, i should've checked before i wrote my dissertation above.
Regarding typeof, i dont know the type from within the DLL, i just know the className (string) - and typeof needs the System.Type (or am i missing something)? Also, are you suggesting because the docs suggest it and (typeof) its faster?

@Bunny83 Thanks for your help as well, some of those suggestions will come handy . PS what happened to your profile?

 

You can not use typeof if you don't have direct access to the types. Yes, typeof would be faster as the type is evaluated at compile time since System.Type objects essentially just wrap the type metadata. Though you can not split your code into seperate assemblies and have both reference each other. As I said, circular references are not allowed / possible.

edit

What do you mean? ^^. The UA profile? Well, UA is horrible inefficient. The more posts you have, the longer the activity feed takes to load. If that's what you meant...

 

makes sense

Yees that's right, i saw 'unauthorized', and wanted to ask (before you mentioned now that number of posts on UA relates to profile performance), whether you made their post counter overflow into negatives crashing their servers or something PEpega JK (coz i remember your post counter being astronomical). But i also vaguely remember you having a different avatar here (might be wrong).