[Solved] Force reload package

Hi @dzamani,

All Assembly Definition files are built before the project assemblies. Their compilation order is determined by the References they declare. This cannot be changed. The snippet you quoted is special startup logic that is not used after startup. After startup, Unity ensures your compiled assemblies are always consistent, so all compilation errors must be resolved before it reloads the active assemblies. Not doing that would lead to all sort of problems with inconsistent states that would be really hard to clear up. E.g. Assembly A got recompiled after being modified, but there's an error in Assembly B's code so we're using the old version of Assembly B... which might be incompatible with the modified Assembly A!

Anyway, the issue you're running into seem fairly clear - basically, any change you make to your package cannot be used by Unity until all compilation errors are resolved, but your changes are meant to fix those errors by fixing the generated code. I might have a couple suggestions:

- Write your Code Gen outside Unity (in a regular .NET solution) and just execute with Unity. You only need some hooks to call you code generator, e.g. in a custom EditorWindow or using your own MenuItems. No need to change to some other language (Python etc.), by the way; you may need to invoke your code generator using Mono if you need cross-platform compatibility.
- Make your code generator data-driven (see Microsoft's T4 templates for an example), so that you can change your code generator output without changing the code generation logic. That's easier said than done, but I've seen it done before.

 

In a way, yes. Nothing guarantees the new DLL is compatible with its previous version, so you might be painting yourself in a corner further.

Say you have assemblies A and B, with B depending on A. You make a change to B's source code, and it no longer compiles; Unity treats this by keeping the last known version of A and B loaded. If you were to change A as well, allow it to compile and be reloaded, then maybe you could have removed some functionality needed by B, so there's no guarantee we could also reload B - that could put you in even more trouble.

Note that this is not specifically related to the Package Manager, but how scripting is handled in Unity.

The code gen can be shipped as a DLL in your package, with the DLL generated from an external VS solution. You can even include its source in your package, by putting it in a folder that's '.'-prefixed (e.g.

.CodeGen

) or '~'-suffixed (e.g.

CodeGen~

). Note that regenerating the DLL would only work while you're working on the package in a way that it's editable; if someone were to add the package after fetching it from a registry, it will be treated as read-only, and any changes made to the package in the Library/PackageCache folder would easily be lost as this is a volatile location.

Well, these inputs don't necessarily require recompiling the code generator, which would break the cycle of "Generator code can't be fixed because Unity fails to compile code generated by Generator etc." Of course, whenever you need to change the Code Generator code itself, you'd be in the same situation - hence my suggestion to move its compilation lifecycle outside of Unity's control.

 

Yes, that might make things a bit more complicated. You could also save it as JSON instead. Since you're already using ScriptableObjects, you can even read/write that directly using JsonUtility (Unity API) in Unity, then you can then read it in your favorite JSON parser in your external project. No need for UnityEditor.dll/UnityEngine.dll in that project.

It still won't be able to use the new one, for the same reason, but if you make it an .exe instead of a DLL, you can launch it using System.Diagnostics.Process. (On Mac/Linux, you'd need to call `mono` with your .NET executable as the first argument instead.).

 

Sure, why not? Conceptually, a (.NET) .exe and a .dll are essentially the same thing, except that one has an entry point for launching it as a separate process, rather than importing the symbols it exports into an existing process.