I have a standalone application that starts with a dll in the plugins folder and working fine. I then run my own small compiler that alters this dll at runtime. The problem is I have to restart my app then the alteration works fine. I have had a look at the article from angry ant, but it seems like his example and scripts is for the web player only. So my question is basically, how can I refresh a dll at runtime using a standalone application?
if the dll is .net nothing is needed to be done.
if the dll is unmanaged then you must restart unity, nothing can be done about that as starting the play mode will load this file with the dynamic library binding and not unbind it so no matter if you change it or not, its there already and until restarted the change is not picked up.
I’ve had this problem in the past too. What i ended up doing was making a seperate dll loader which wrapped all the functions via LoadLibrary GetProcAddress, FreeLibrary and on mac CFBundleCreate, CFBundleGetFunctionPointer, CFRelease.
Its certainly a pain, but it solved the issue for me. I really wish unity editor would let you flag certain dlls as only to be ran in play mode.
the problem is not the ‘having it run’ the unity editor does what the player does, upon start playing it loads all dlls … problem is that happens on process level and the play mode is only a thread within the editor process so when the play mode ends, the dll is still bound. Optimally the bug would be fixed and dlls finally get unloaded at end of play mode and OnApplicationQuit would be fixed along the same fix to finally be respected in editor too
Actually it doesnt load any plugin native dlls until a call is attempted on them via some function with DllImport, this goes for editor and standalone. But yes, regardless of standalone or editor it keeps a ref to them until the process is closed
I would really appreciate it if unity unloaded dlls/bundles from monoscripts when it goes through and resets static variables with play mode ending.
Ultimately though, while it’s complete overkill to have your native code set up to run a way it wont actually run at runtime ( like avoiding static initializers, relying on DllMain, or constructor/destructor attributes (mac) ) thats probably the simplest way to go about that. If your like me though you end up writing a quick wrapper module.
My dll is compiled with the .net c# (csc) compiler. Does this necessarily mean that it falls under .net and it is managed? I have been reading a couple of articles and it most certainly looks like it is managed? Here is an example of the cs file that I compile into a dll, pretty basic…
using UnityEngine;
using System.Collections.Generic;
public class userFormulas: MonoBehaviour
{
public static Dictionary<string, float> userFloats = new Dictionary<string, float>();
public static Dictionary<string, Vector3> userVector3 = new Dictionary<string, Vector3>();
public static void calc()
{
userVector3["U"] = userVector3["U"] + userVector3["A"] *Time.deltaTime * 5;
}
}