Closed rogerbarton closed 4 years ago
Interesting idea. I would however see this myself implemented as a interface or attribute which user implements and uses of which are picked up dynamic by reflection (probably attribute, because interface would have to be instantiated). This way user wouldn't need to access source, which could be replaced after update (in case I find anything to update). I can implement this myself, if you're not willing to.
Indeed that would be a cleaner solution. I don't have much experience with writing Attributes/Reflection myself so if you know how to do it that would be great.
btw, I currently use this callback functionality (OnDllLoaded) to initialize my native plugin and set up delegates/function pointers in C++ and it works quite well.
btw, I currently use this callback functionality (OnDllLoaded) to initialize my native plugin and set up delegates/function pointers in C++ and it works quite well.
Well, this sound's like you're going to use this technique (and, therefore this tool) in the final code, which is not intended. It was designed to help hot-reloading plugins when developing in the editor, and although it may very likely work in production build, I do not guarantee it (I'd be quite surprised if it didn't though). Specifically, note that it's not going to work on android or non x86 based processors. I may actually update it to do so, but I haven't felt such need yet. In your case you may simply create a script that runs the dll init code in e.g. OnAwake and set it's execution order to be lower than other scripts that access the dll (but not than DllManipulatorScript).
This is a valid point. I do not intend to use this in a build and currently use a static constructor for this with #if UNITY_EDITOR
etc.
However, this ties together with using this tool in edit mode PR #12. As the plugin should be initialized when it is loaded, not only when Awake
/static constructor is called. A plugin may be rebuild, and so reloaded, several times within an editor session (via shortcut PR #10). So it is actually necessary to get this callback rather than use Awake
so the plugin can be re-initialized.
Yup, I see
I've implemented it myself in 6c6b17c36b33c72754d0bf2ee7e7236a68e10665 using dynamic target resolving. I hope that meats your intentions.
Yes, I've tested it and it works great, thanks! That quite a nice solution.
Allows users to write their custom code in these callback functions inside the DllCallbacks.cs file. Implemented: OnDllLoaded, OnBeforeDllUnload, OnAfterDllUnload Currently only the name is passed as an argument, this could be extended to be the NativeDll class (which is currently internal)