KSP-ModularManagement / KSPe

Extensions and utilities for Kerbal Space Program
http://ksp.lisias.net/add-ons/KSPAPIExtensions
Other
11 stars 6 forks source link

Prevent `KSPe` from initialising itself twice. #51

Closed Lisias closed 1 year ago

Lisias commented 1 year ago

KSPe.InstallChecker has a borderline use case that is getting screwed by issue #50 : when the user reinstall KSPe from scratch using the same Release.

This was not happening until https://github.com/net-lisias-ksp/ModularManagement would to be, as this package can be reinstalled updating something else but keeping KSPe the same.

This is harmless on KSP >= 1.8.0 where multiple Assembly loading was short-circuited, but it was undesired before it as things would be loaded on a different AppDomain, taxing all the calls due internal serialisation. See https://learn.microsoft.com/en-us/dotnet/framework/app-domains/how-to-load-assemblies-into-an-application-domain for more information.

With #50, this became a fatal error as since the previous incarnation had already loaded the auxiliary DLLs, the code is barking on it now.

Instrument KSPe to prevent initialising itself if it detects another instance of it in a way that save our sorry arses in KSP < 1.8.0 but do not screw up KSP >= 1.8.0

Lisias commented 1 year ago

Implemented on commit https://github.com/net-lisias-ksp/KSPe/commit/88f3a6720b65df72082a2af73694dede8ee4bd1d .

It worths to mention that, besides hot deleting DLLs on a live KSP session is usually a bad idea (since this potentially screws up Reflection), on this case it is… relatively safe as I'm not removing every instance of the DLL, as it's happening with ZeroMiniAVC. See https://github.com/sarbian/ModuleManager/pull/177 for details .

When using Reflection, KSP (or Mono?) always pinpoints to the first loaded Assembly, as it appears, and since KSPe.InstallChecker is preserving the first one to be loaded, no harm is done.

Lisias commented 1 year ago

Closing it as Fixed.

Lisias commented 1 year ago

This code was rolled back, it will not reach the mainstream.

Issue #50 implements a better solution.

(screw that - the code will stay)