I’m working on an Enterprise App that is starting to lean more into Asset Bundles instead of one monolithic Build.
Much of the app is procedural and run-time based. We use lots of prefabs but all are instantiated at run-time and acted upon with code OUTSIDE of MonoB’s.
Could I (in theory) create a separate assembly definition “AssetBundleCode” and have it compile to “AssetBundleCode.dll” and swap versions of this out of the Build Folder?
I’m Assuming each Build does GUID matching between its supporting dlls and this would NOT work. Has anyone tried this before?
You can build a DLL of your own, created and edited in a separate .csproj with or without UnityEngine references. I think these DLLs actually end up verbatim in your build output folder(s). This DLL has to be placed somewhere under /Assets in the editor to make it accessible by other scripts.
But if this DLL gets bundled within the output package files, it might still be solvable by having separate workflows between editor and runtime. I believe there’s some sort of automatism in .NET where if an assembly isn’t loaded it will try to load that DLL in the working directory first. So it may be as simple as adding the updated DLL in the same folder as the exe - or not. It may require managing loading your DLL into the domain and perhaps differently depending on editor vs runtime. But it definitely sounds like something that’s absolutely doable one way or another.
I’m surprised this hasn’t been tried more…as it seems like the best of both worlds. Or maybe most don’t have the flexibility since they’re publishing games on platforms vs. building for enterprise.
I’ll keep exploring and report back on success/failure.
Mostly that. But also “modding” … with that, you aren’t replacing built-in code but rather extend it.
Perhaps that is also a suitable solution for you? Provide hooks into the application and be able to register any number of additional plugin DLLs. You can also build this in a way that you can override/replace built-in functionality by requiring the built-in functionality to register with an orchestration system or service locator, so that DLLs can throw out that registration and put themselves in the place of the built-in module.