Let’s say I have class Foo in assembly A. I also have class Bar which derives from Foo in assembly B. I then change class Foo and rebuild assembly A, but without braking Foo’s interface. Will class Bar from assembly B work normally? Will I have to recompile also assembly B? I need this for modding support.
DLLs are modules that have to be located and loaded when they’re needed at runtime (hence their name - dynamic link library). In contrast for e.g. static libraries (see C/C++ for example) they’re not included in another assembly /executable.
Of course you need to link them in your project, but that’s mainly for syntax and type resolving of the contained types and to gather some information for later usage during runtime.
That’s how updates and patches for many things work, this is how stub implementations can be used, and that’s also a reason why DLL injections work in the first place (replacing existing .dlls with some that have been tampered with).
So this does usually work, unless you use strongly-named (signed) assemblies. They’re resistant against it.
The question is whether that is a good way to introduce modding support. I doubt. I’d rather provide modding support on top of everything, not at the base of everything as this can mess up your application that relies on on it. E.g. your derived types could suddenly get into invalid states if someone messed with the base implementation.
1 Like
My idea is that people would derive from base types from my main game assembly. For ex. Command object allows creating Console/Terminal commands. People would create their own commands by deriving from game assembly type Command in their mod assembly. This would be the solution for most types of mods. People would simply subclass something from the game assembly and implement IExtension interface so that I could detect through reflection that something is a mod. This way it is rather hard to break any contracts. I create full system abstraction for my game which will be based upon a public, documented API.