Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Fix ObjectCreator assembly resolving on Windows. #13190
This fixes an issue that prevented out-of-tree compiled dlls from loading on Windows/.NET.
It appears that the assembly resolution on Windows is lazier than mono, and in this specific case does not try to resolve the Mods.Common dependency until after we have removed our custom assembly resolver.
This then leads to the following exception:
I don't understand why it fails here but works for our main mod dlls. The
Behaviour under mono should not change.
I guess that this explains why third party mods have always insisted on / resorted to hacks to put their dll projects in the main code tree, but I don't understand why it hasn't been reported or seriously discussed as a legitimate engine bug before now.
Requesting reviews from:
This is past above my head at the moment and I don't have time to review this properly, but this sounds like the reason why crashes like OpenRA/ra2#334 (comment) (yes, this was reported on OSX, but the end result is suspiciously similar) happened?
In any case, I never heard this bug myself, my insistence on the "hack to put the dll in the main code tree" is simply personal preference because I hated building against the compiled binaries in VS (and didn't even gave that a try after Linuxswitch) since that prevented me jumping from one code snappet to another through Go To Definition.
FYI you don't need the code to be in-tree to do this, and I plan to have the mod template support this. If you want to continue this discussion lets move it to IRC to avoid side-tracking this PR.
The description of the issue you provide here is sound. On Windows, assemblies are loaded super lazily so the custom assembly resolution would indeed be removed before any of them were actually loaded. Keeping the assembly resolution active during the lifetime of the
ObjectCreator is the way to fix that.