So when Unity reloads assemblies, the serialization process comes in to store data on the native side of unity to restore it back once the assemblies get reloaded.
But, will the data in DLLs get wiped out, too? Basically, are the DLLs reloaded, too, even if they did not change and theoretically wouldn’t need to be recompiled?
I have some very hard to serialize data (delegates, possibly anonymous) and I have the possibility to embed the editor-side code into a DLL, if that helps me in any way around the serialization problem.
The background: I’m working on an action-based Undo system integrated into the default Undo system, using reflection of course. It works really nice now, but the problem I’m encountering is that all the data storing the custom action-based undo records get’s wiped out. This HAS to be avoided at any cost to match unity’s default behaviour obviously.
I just thought if it is possible by using a DLL or, if it is the only solution (if at all) a native library.
Thanks!
Well, managed DLLs are assemblies. The whole scripting environment is restarted / reloaded. So you end up with a new AppDomain and all assemblies have to be reloaded, no matter if they got recompiled or if they are precompiled. I’m not sure about native DLLs, i’ve never really used those in Unity.
If you talk about managed delegates / anonymous methods then native DLLs are out of the question.
Technically it’s possible to serialize delegates, even those to anonymous methods. However if the actual method is an instance method (for example when it’s a closure) the containing object need to be serialized as well. If the containing object is a MonoBehaviour you don’t have to worry about serializing the object. Though if it’s a “normal” class (which includes auto-generated closure classes) you need a way to serialize them manually. Since those classes usually aren’t serializable by most .NET serializers, you might need a special serializer.
In the end you should ask yourself if that’s worth the trouble. Where and how are those “actions” defined? Do you only have predifined actions or should it be a system to allow other users / developers to kind of “register” those actions?
What exact assembly reload do you talk about?
- Reload when a recompile happens after a script change
- Reload when you change playmode?
- Reload when you restart Unity or when you change scene / project
In all those cases some sort of serializing, destroying, recreating and deserializing happens. Static variables usually survive case 2 but are wiped in case 1 and 3.
I’ve created a serializable wrapper class for System.Type and MethodInfo. Both can be used to construct a serializable delegate. I’ve started such an approach some time ago, but was interrupted and haven’t finished it. Of course the actual delegate target object need to be handled different based on if it’s a Unity serialized type (derived from UnityEngine.Object) or a normal managed class type. References to UnityEngine.Objects can be serialized in Unity, normal classes has to be serialized manually.
The UnityEvent class does something similar, but can only serialize references to UnityEngine.Object derived classes. As you said yourself it’s quite difficult to get that done right. If you really need it, there’s no way around serializing that information in some way.
If you have created a new project . Your data of the last project will be wiped out temporarily . Moreover the Asset files will remain untouched . If you will again open the last project , the scene will be blank , if you want your scene back , you have to open it from whee you saved the scene , maybe in asset folder or something . (E.g - You are working on Project1 , You wanted to make a new project naming Project2 , Now if you want to again switch back to Project1 , You will simply Open Project naming Project1 but the scene will be found empty . To get your scene back , you have to open the scene from the project panel from the specific folder you saved the scene in) . And yes , don’t waste your time in DLLs .