4 ms·
This is Microsoft's most recent advice about in-process Explorer shell extensions: https://docs.microsoft.com/previous-versions/windows/desktop/legacy/dd758089(
by hyperrail 6y ago
This is Microsoft's most recent advice about in-process Explorer shell extensions: https://docs.microsoft.com/previous-versions/windows/desktop/legacy/dd758089(v=vs.85) https://docs.microsoft.com/previous-versions/windows/desktop...
The advice is still "don't use .NET managed code for your in-proc shell extension", but the given reasons are not necessarily specific to the .NET runtime:
1. The .NET framework CLR takes too long to load for an extension that could be loaded by any app that pops up shell UIs.
2. There are seams between .NET and COM even with interop. These seams open traps for you because the COM-era shell APIs (Windows 95 to Windows 7) were designed for people who write their shell extensions in C++ and so can deal with all the tricky details of COM.
- ComputerGuru 6y agoPoint 1 was temporarily obviated by .NET Native, but that has now been abandoned with no explicit replacement, leaving a hole only somewhat filled by a combination of Mono and CoreRT.
- WorldMaker 6y agoThe explicit replacement was CoreRT. It's built in to the options of the dotnet CLI tool as of .NET 5, and supposed to get more complete as the Mono merger finishes early in .NET 6.
- pjmlp 6y agoActually if you look at the github issues and Build 2020 talks it still isn't quite clear how it goes. Apparently they are more keen into going into a AOT + JIT mixed model, with the RoR (Ready to Run) images, specially if you take into consideration the talks done as guest at JVM Languages Summit 2019.