Remove dependency on .NET SDK installs for IL Tools

[rladuca]

Fixes #2298

Use a set of matched, private IL tools in order to inject a module constructor into PresentationCore. These are copied binaries from a .NET Framework 4.7.2 installation and SDK.

Also fixing some issues with utilizing ILAsm outside of the installed Framework directory and some bugs that went unnoticed in our injection targets.

Pending

• IL comparison between PresentationCore from this change and current .NET 5.0 PresentationCore.

[vatsan-madhavan]

You have to undo @SamBent's documentation update.

[vatsan-madhavan]

Instead of inventing new targets for ILAsm/ILDasm, you can reuse those supplied by Microsoft.NET.Sdk.IL.targets that comes as part of Microsot.NET.Sdk.il package, and override ILAsmToolPath ?

As long as the commandline usage have remained largely compatible between .NET Framework and .NET Core versions of ILAsm/ILDasm, I suspect that this would be doable.

[rladuca]

Instead of inventing new targets for ILAsm/ILDasm, you can reuse those supplied by Microsoft.NET.Sdk.IL.targets that comes as part of Microsot.NET.Sdk.il package, and override ILAsmToolPath ?

As long as the commandline usage have remained largely compatible between .NET Framework and .NET Core versions of ILAsm/ILDasm, I suspect that this would be doable.

I don't think those targets are fully featured. While you can override the IL(D)AsmDir properties to choose non-package based tools, it seems there is only a target to decompile resources and a target to compile an IL file. They also don't accept some switches that we use. Generally, they seem created for a specific purpose and not for general use unless I am missing something.

[vatsan-madhavan]

Generally, they seem created for a specific purpose and not for general use

😞

[rladuca]

IL comparison seems fine, no major differences there between corresponding release DLLs.