koobas.hobune.stream
Obfuscating DLL classes from the users
This might sound like an odd request, but here goes:
So I'm writing a DLL where many classes are MonoBehaviour scripts. However, I don't want my users to directly access certain scripts (no dragging them to objects, no calling AddComponent() on them, etc).
I'm trying to make this library a black box, so if they want to make an object with one of those scripts, they need to request it through the one main script in the DLL that is available.
Is there a way to hide scripts in a DLL from the user, or at least, is there a way to make sure users can't directly add scripts either dragging or calling AddComponent()?
Disabling addcomponent should not be possible from the chain of inheritance monobehaviour->behaviour->component. So all your classes inheriting from monobehaviour in the dll will have type component and can therefore be added using add component. One way to make sure that aspects of the dll are hidden would be to use the internal keyword and possibly user the TypeBuilder class to create the types on the fly. This way you could use a factory to return new instances of the types that you actually want to create. This should also help with addcomponent.
Components can only be created with AddComponent. You cant create them with "new".
If the user shouldn't be able to attack those scripts to GameObject, why are they $$anonymous$$onoBehaviour scripts?
The reason is that we want a unified look and behavior for specific menus along all the products we're making. We're a big company, so our little studios have a tendency to take what we make for them and modify it somehow for their ends, then complain when it breaks because of their modifications.
We want to avoid that whole ordeal by giving them only the access to create the menu and hook certain callbacks to it for info. In other words, we're trying to take away the gun that they shoot their foot with.
I've been successful so far in making it a standalone library, except I'm concerned that having the classes exposed in Assets can be a problem. If they wanted to, they could make their own menu layout and just hook the logic in, and now we have different looks across our products, headache, etc.
It's not possible since Unity has to register all MonoBehaviour classes in the AssetDatabase to actually be able to attach it to a GameObject. If you manage to hide it from Unity, you won't be able to attach it to a GameObject.
What you can do is create a MonoBehaviour wrapper class that get linked to one of your custom classes. However such a construct can't be serialized by Unity, so you have to find your own way. I don't see the reason for this anyway.
edit
Ok if it's just to save the user from extending stuff they shouldn't, just make your classes sealed like Unity does with it's internal stuff.
Since Mono is a managed environment you can't prevent others from decompiling / reuse your code. If they do and they get in trouble that's their problem ;) Obfuscating is nice, but doesn't help much. Reuse is always possible.
I wouldn't even try to prevent the user from adding a certain component to a GameObject. That just irritates the user more than it's useful and might even break things. It's better to implement some checks in the component if it has been created "correctly". this could be done by adding a serialized hidden value which get set by your creator script.
Make use of Debug.LogWarning (or in rare cases Debug.LogError) to inform the user what's wrong.
You could immediately remove the component whenever it's added, either by using [ExecuteInEdit$$anonymous$$ode] or by using a custom editor.
