Does the DLL-stored data survive assembly reloads?

Question

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!

Answer 1

Best Answer

Answer by Bunny83 · May 12, 2016 at 08:57 PM

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.

2 Show 7 · Share

Bunny83 · May 12, 2016 at 09:00 PM 0

Share

Just to make that clear: There are no "anonymous methods". This is a pure language feature of C# or UnityScript. The actual underlying IL code can only work with class methods. The compiler generates closure classes and manages the instantiation of those behind the scenes, but in the end every method is declared within a class, no matter if an anonymous method or lambda expression.

Seneral · May 13, 2016 at 04:22 AM 0

Share

Thanks very much for the detailed answer! To answer your questions: They all have no parameters fortunately, but any developer can define it in any way they want. If it's not possible to serialize anonymous actions then I'd be ok with throwing an error... The actions are Undo records, so they have to live within the scene and survive playmode changes and script change assemblie rloads. I set the data to be in a hidden gameobject, which does work just fine serializing stuff as required (besides actions).

I approached to create a SeralizableAction based on this answer, it is a combined version that handles both System.Object and UnityEngine.Object when the method is non-anonymous:)

So when it is anonymous, serializing the methodinfo with your method should do it, right? Don't know about the target, as it is a completely new class generated by the compiler, so serializing the type and recreating the object might do it...

Seneral · May 14, 2016 at 11:50 AM 0

Share

Finally! I've managed to make a SerializableAction that suited my needs (Single-cast only, no parameters) that handles all types and possible combinations of (Normal, GenericDeclaringClass, GenericMethod), (Static, Instance, Anonymous), (UnityEngine.Object, System.Object), ...

So in the end, it wasn't THAT hard. Thanks to your SerializeableMethodInfo/-Type (which I both added to and improved a bit), it is now fully serializeable (with exception of multi-cast and method parameters of course). Thank you very much!

If anyone wants the source, here is the SerializableAction, needing both the modified versions of SerializableMethodInfo and SerializableType. Here is also an test editor window providing every possible combination so you see everything works (tested with both playmode switches, scene switches and script reloads, everything works). Thats it, thanks Bunny!

Seneral · May 14, 2016 at 08:22 PM 0

Share

Ok, one limitation regarding anonymous methods: If the anonymous action references a local variable, the compiler will create an extra class for it, and that is not serializable unfortunately, so it will throw an error. But if it references no local variable, it's fine...

EDIT: This answer explains the reason for this error, because we can serialize static methods out of non-serializable classes but not instance methods...

Bunny83 Seneral · May 14, 2016 at 08:44 PM 0

Share

Well, i don't see a direct problem why you can't serialize a closure class. Of course it's not marked as serializable, but with some reflection magic it should be possible. However the question is if it's worth the hassle ^^. A closure class instance might be referenced by other classes as well in order to actually work on the same instance. But if you only serialize things that are directly connected to your delegates you might be missing some important things. Creating a general solution would require you to handle the serialization of everything yourself so you are able to keep track of instance references between all classes involved.

I'm not sure if that's what you want to do ^^. Anyways nice to hear you actually got somewhere.

ps: your "one drive" links require a microsoft login which is semi optimal for sharing your version ^^. However you are not required to share your actual solution.

Seneral Bunny83 · May 14, 2016 at 09:19 PM 0

Share

Thanks for the answer, it's definitely not worth that much hassle indeed, but using the context is actually one of the main reasons to use anonymous methods/actions :( ... But I'll definitely don't want to create/use a completely rework of the serialization system, even right now the serialization makes up half of the whole project (Undo integration) and I'll definitely don't want to exceed this...

Also, thanks for notifying me about the login... didn't know that. Moving links to dropbox:)

Show more comments

Answer 2

Answer by Prasenjit_LinuxGuy · May 12, 2016 at 06:02 PM

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 .

0 Show 1 · Share

Seneral · May 12, 2016 at 08:06 PM 1

Share

I think you completely misunderstood my question:O The question I'm asking is about the serialization system of unity and how to overcome messing with it (potentially by using a dll; in the end, it did not work). Anyway, thanks for trying to help me:)

Does the DLL-stored data survive assembly reloads?

2 Replies

Your answer

Welcome to Unity Answers

Follow this Question

Related Questions