Installing Everest with coreified vanilla always fails and deletes Celeste.dll

[SnipUndercover]

My mods and Everest install are up to date

Yes

I have recreated the bug with only Everest OR a minimum number of mods enabled

Yes

Describe the bug

Installing Everest with a coreified orig/Celeste.exe will always fail and delete Celeste.dll, but not the apphost.
This is what causes the "entity not found: path/to/Celeste.dll" message box when trying to run Everest.
This is a side-effect of #983.

Steps to reproduce

1. Install Everest with a coreified orig/Celeste.exe (see orig/Celeste.exe is coreified and does not run #983)
2. Wait until it fails
3. Try to run Everest

Expected behavior

Celeste.dll does not get deleted / the installation succeeds.
This situation shouldn't be happening at all.

Operating System

N/A (OS-agnostic)

Everest Version

5580, but likely applies to all core (4465+) versions

Mods required to reproduce

No response

Additional context

The issue arises because MiniInstaller.DepCalls.ConvertToNETCore returns early if it sees that the source assembly is already coreified, without copying it to the destination (line 103).

Everest/MiniInstaller/DepCalls.cs

Lines 92 to 117 in 676c509

	public static void ConvertToNETCore(string asmFrom, string asmTo = null, HashSet<string> convertedAsms = null) {
	asmTo ??= asmFrom;
	convertedAsms ??= new HashSet<string>();
	if (!convertedAsms.Add(asmFrom))
	return;
	// Convert dependencies first
	string[] deps = MiscUtil.GetPEAssemblyReferences(asmFrom).Keys.ToArray();
	if (deps.Contains("NETCoreifier"))
	return; // Don't convert an assembly twice
	foreach (string dep in deps) {
	string srcDepPath = Path.Combine(Path.GetDirectoryName(asmFrom), $"{dep}.dll");
	string dstDepPath = Path.Combine(Path.GetDirectoryName(asmTo), $"{dep}.dll");
	// Don't convert steamworks - doing so would copy it from the vanilla backup location instead of taking our updated version.
	bool isSteamworks = MiscUtil.IsSteamworksNet(srcDepPath);
	if (File.Exists(srcDepPath) && !MiscUtil.IsSystemLibrary(srcDepPath) && !isSteamworks)
	ConvertToNETCore(srcDepPath, dstDepPath, convertedAsms);
	else if (File.Exists(dstDepPath) && !MiscUtil.IsSystemLibrary(srcDepPath) && !isSteamworks)
	ConvertToNETCore(dstDepPath, convertedAsms: convertedAsms);
	}
	ConvertToNETCoreSingle(asmFrom, asmTo);
	}

MiniInstaller tries to coreify vanilla, but since this method returns early, it does nothing. Because of that, the Celeste.exe apphost is not deleted.
Then, when running MonoMod, it tries to resolve the Celeste assembly, it finds the apphost instead and dies a brutal death.

Everest/MiniInstaller/Program.cs

Lines 85 to 90 in 676c509

	DepCalls.ConvertToNETCore(Path.Combine(Globals.PathOrig, "Celeste.exe"), Globals.PathCelesteExe);
	string everestModDLL = Path.ChangeExtension(Globals.PathCelesteExe, ".Mod.mm.dll");
	string[] mods = new string[] { Globals.PathEverestLib, everestModDLL };
	DepCalls.RunMonoMod(Path.Combine(Globals.PathEverestLib, "FNA.dll"), Path.Combine(Globals.PathGame, "FNA.dll"), dllPaths: mods); // We need to patch some methods in FNA as well
	DepCalls.RunMonoMod(Globals.PathCelesteExe, dllPaths: mods);

Since MiniInstaller deletes Celeste.dll in the beginning and does not do any cleanup after installation fails, Celeste.dll is gone while the Celeste.exe apphost remains. Running the game at this point yields the "entity not found: path/to/Celeste.dll" message box that has been plaguing #modding_help for ages.