由于 VSTO 还没有移植到 .NET Core，我可以用老式方法创建一个非托管 shim 来加载 CLR 并托管托管的 .Core 5 加载项吗？
我的特定用例是一个 Outlook COM 加载项，它目前是使用 VSTO 针对 .NET 框架 4.7 构建的，但我想开始利用 .NET 5。就与 Outlook 的交互而言，它只是在功能区上添加了一些按钮并制作了一个很少调用 Outlook 对象模型。例如，我不需要在 Excel 中执行基于 VSTO 文档的加载项之类的操作。
我不想走 JS 路径，因为有相当多的 C# 代码需要移植。
我发现了这个https://github.com/jozefizso/COMShimWizard/releases，它展示了如何使用 .NET 框架进行操作，并且假设它与 shim 向导在 VS 2010 中所做的非常接近，如果不完全相同的话。
由于我需要加载 .NET 5，我相信要加载 CLR，我需要按照此处概述的内容做一些事情：https ://docs.microsoft.com/en-us/dotnet/core/tutorials/netcore -托管。
在我进一步深入研究之前，这种方法可能有效吗？特别是，是否有可能进行必要的 COM 操作来实例化托管组件？
并且假设所有这些都是可行的，这是否或多或少等同于 VSTO 为 .NET 框架 4.x 所做的，即它是否在任何方面都不太安全或性能，或者是否会有任何功能不可用内置 VSTO 的加载项？
更新 1
我做了一些更多的研究，提出了一些额外的潜在问题。
- 对于 .NET 框架的情况，一旦将一个类加载到 CLR 中，“解包”返回的引用以获取可用于访问该类型实现的 COM 接口的 COM 指针相对容易。我不清楚在使用 netfxr 接口加载 .NET Core 运行时时如何做到这一点。
- .NET Core 没有应用域的概念，这是否意味着加载到 Core 运行时的多个加载项不会被隔离，或者有办法实现某种程度的隔离？从我读过的内容来看，他们的堆似乎至少会被隔离，但我不确定。
更新 2
从阅读此https://github.com/dotnet/runtime/blob/main/docs/design/features/COM-activation.md看来，在 Core 中，将程序集类型作为 COM 服务器的请求将导致自动加载核心运行时（如果尚未加载）并在单独的 AssemblyLoadContext 中创建对象，因此可能根本不需要 shim？另一方面，如果核心运行时已经加载并且版本确实与您尝试创建的类型所要求的匹配，那么该类型将无法加载，所以这似乎是一个问题......