Runtime: 在 Windows 上支持混合模式程序集

Paint.NET 作者在这里......你引起了我的注意：DI 有 50 个 KLOC 的 C++/CLI 代码......如果你需要一只豚鼠，请告诉我：）

谢谢，@rickbrew。 我们还需要一段时间才能为 Paint.NET 做好准备，但我们会记住您的。

我认为我们可以从恢复https://github.com/dotnet/coreclr/commit/1aa7d6b8796f7e28a63162117c5bb16a207a472b开始，至少允许加载多模块程序集的能力。

@mjsabby ，多模块程序集与混合模式正交。 （多模块意味着您使用 alink.exe 将网络模块链接在一起，混合模式意味着您在同一程序集中拥有托管代码和本机代码的组合）。 如果您需要多模块程序集，我建议您提交一个单独的问题，概述您的需求。

@morganbr谢谢。 我不确定为什么我得出 C++/CLI 需要 netmodule 支持的结论。

太棒了，我们正在这方面取得进展。 我们使用 C++/CLI 将本机服务连接到令人敬畏的 .NET 世界。 到目前为止，没有其他替代方案能够像胶水语言一样实现 C++/CLI 的优雅，因此可以说我们将依赖 C++/CLI 作为我们服务的一个组成部分。

前一段时间，本着通过从 .NET 框架迁移到 .NET 核心来寻求性能提升的精神，我遗憾地发现 .NETCore 不能与 C++/CLI 一起使用（即使我们还不关心跨平台） .

现在这个帖子让我心情好起来👍 期待发布（在我搜索解决方案时，我看到很多人在他们自己的项目中对 C++/CLI 有同样的需求）

@morganbr鉴于“将混合模式程序集加载到运行的托管代码中”已完成，是否可以在 Windows 上将最新的 .NET Core 3.0 预览版与混合模式程序集一起使用？ 例如来自 C# 应用程序？

我们打算将 .NET Core 3.0 与 WPF 一起使用，并且有相当多的 C++/CLI 依赖项/库（也有很多第三方），所以很期待。

@nietras ，我很高兴听到您渴望尝试一下。 不过，使用最新的预览版进行尝试可能还为时过早。 虽然运行时现在可以运行混合模式程序集，但 C++ 编译器还需要一些更改才能使一切顺利运行。

如果有人对细节感兴趣，主要的 C++ 编译器更改是：

1. 能够针对 .NET Core 程序集而不是 .NET Framework 进行构建（这不是严格阻塞，但如果程序集引用不在 Core 中的类型或想要使用不在 Core 中的类型，则会导致问题框架）
2. 使用当前版本的 C++ 编译器构建的程序集将在启动时加载并调用 mscoree.dll，从而启动 .NET Framework。 正如您想象的那样，让两个运行时都认为它们加载了程序集会导致很多问题。

@morganbr对支持 .NETCore 的 C++(CLI) 编译器的更改会与下一版本的 Visual Studio 一起发布，还是会带外发布？

@pongba ，我认为我们还没有准备好确切地说我们何时或如何首先分发该版本的编译器，但它最终会与 Visual Studio 一起分发。

那么是否可以使用 .net core 3.0 的当前预览加载其中包含 ddlexports（vtfixup 等）的程序集？ 我问这个是因为在尝试加载我用 .net core 3.0 编译并使用 ildasm 和 ilasm 添加导出的程序集时，我只是遇到了 BadImageFormat 异常。 使用 .net 4.6.2 编译时，相同的代码有效。 如果需要，我可以提供 il 代码作为再现。

考虑到C++/WinRT ，是否可以为 .NET Core 编写标准的 C++ 投影？

@morganbr很高兴收到您的回复。 无法至少加载包含 dll 导出的程序集阻止我将https://github.com/cplotts/snoopwpf移植到 .NET core 3.0。

@batzen ，您可能会遇到一些不同的问题。 您可以通过查看在 .NET Core 进程中直接对程序集调用 LoadLibrary 是否有效来缩小它们的范围。 一些可能的问题：

1. 处理器架构不匹配（特别是，.NET Core 默认为 x64，而 .NET Framework 默认为 x86）
2. 根据您的导入/导出设置的准确程度，您的程序集可能会导致加载 mscoree.dll。 如果发生这种情况，它会尝试启动 .NET Framework，并且可能会发生各种不好的事情（包括 BadImageFormat）。 如果您启用了混合模式调试，您应该能够在调试器中发现 mscoree.dll 加载。
3. 特定于您的 ildasm/ilasm 流程的内容。 您需要进一步调试该错误，以确定是否存在您依赖的特定于 .NET Framework 的内容。

@Berrysoft ，.NET Core 支持 WinRT，尽管某些功能可能仅在 UWP 应用程序中可用。

@morganbr哦，不，我的意思是，当前的 C++/CLI 语法是非标准的。 可以用标准 C++ 语法对 .NET Core 进行投影，以便其他标准 C++ 编译器编译代码，就像 C++/WinRT 对 WinRT 所做的那样？

@morganbr

1. 架构还行。 尝试了 x86 和 x64。
2. 这是一个纯粹的 .net core 3.0 程序集。 没有提到 mscoree。 一个类中只有一种方法。 IL 代码可以在https://gist.github.com/batzen/8b1ed3e7269b4aaaacee846f188ef347找到
3. 我只是在 Gist 中的 IL 代码上运行ilasm ManagedCore.il /outfile=ManagedCoreExported.dll /dll 。

对 .NET 框架的等效 IL 代码执行完全相同的操作，然后当然包含 mscoree 引用，在没有 BadImageFormatException 的情况下工作。
修改后的程序集的加载是通过Assembly.LoadFile 。

如果 .NET Core 3.0 支持混合模式程序集加载，是否有可用的示例？ 你可以指点我的一些单元测试吗？

由于现在已分配此问题，我想您能够重现它吗？

@batzen .NET Core 3.0 尚不支持混合模式程序集。 此问题正在跟踪该支持。 @jkoritzinsky正在积极致力于调查需要发生的事情以及需要引入的更改。 在接下来的一两周内寻找有关此的设计文档。

@AaronRobinsonMSFT如果加载混合模式程序集当前不支持此问题中的任务点“将混合模式程序集加载到运行的托管代码中”应该取消选中，不是吗？

@batzen我们支持将混合模式程序集加载到运行托管代码中，并使用一些特定的解决方法来避免将 .NET Framework 意外加载到进程中。 该功能的运行时工作已经完成。

当从本机代码而不是托管代码加载混合模式程序集时，我们仍在努力启动运行时，并在需要时启动运行时。 此外，还有一些编译器工作需要让 Visual C++ 编译器链接到 .NET Framework 的 mscoree.dll 以外的其他东西来加载运行时。

支持在非混合模式程序集中设置 vtfixup 表是我认为是您问题的基本问题的另一件事。

是否有关于如何为 dotnet core 3.0 设置混合模式程序集以及如何将其加载到正在运行的托管应用程序中的示例？

//爱

在我的手机上

来源：杰里米Koritzinsky [email protected]
发送时间：2019 年 2 月 4 日星期一 22:38
至：dotnet/coreclr
抄送：奥维巴斯蒂安森； 手动的
主题：回复：[dotnet/coreclr] 支持混合模式程序集 (#18013)

@batzen https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fbatzen&data=02%7C01%7C%7C014210d3b7f34fdd9b3e08d68ae91c40%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636849131130015110&sdata=lF30W2mA8AdheQqc30GIRdf5uAxNX%2B0wBN5gLX33ZaQ %3D&reserved=0我们支持将混合模式程序集加载到运行托管代码中，并使用一些特定的解决方法来避免将 .NET Framework 意外加载到进程中。 该功能的运行时工作已经完成。

当从本机代码而不是托管代码加载混合模式程序集时，我们仍在努力启动运行时，并在需要时启动运行时。 此外，还有一些编译器工作需要让 Visual C++ 编译器链接到 .NET Framework 的 mscoree.dll 以外的其他东西来加载运行时。

支持在非混合模式程序集中设置 vtfixup 表是我认为是您问题的基本问题的另一件事。

—
您收到此消息是因为您订阅了此线程。
直接回复本邮件，在GitHub上查看https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fcoreclr%2Fissues%2F18013%23issuecomment-460422911&data=02 ％7C01％7C％7C014210d3b7f34fdd9b3e08d68ae91c40％7C84df9e7fe9f640afb435aaaaaaaaaaaa％7C1％7C0％7C636849131130025114＆SDATA = hpgDfah2UN5vjCgi84BWB7BhxqggitHhvwB78％2Bnl％2FQM％3D＆保留= 0 ，或静音螺纹https://eur04.safelinks.protection.outlook.com/?url=https%3A% 2F％2Fgithub.com％2Fnotifications％2Funsubscribe-AUTH％2FAQSuAeLAM3EyGvUwgCMu8BnkzuyhtDTFks5vKKhXgaJpZM4UAdnr＆数据= 02％7C01％7C％7C014210d3b7f34fdd9b3e08d68ae91c40％7C84df9e7fe9f640afb435aaaaaaaaaaaa％7C1％7C0％7C636849131130025114＆SDATA = gcW6PgaOqzl6NVHQLRFP51azZHHDiQ6Y0igINNmbrFk％3D＆保留= 0 。

你好。
在创建 c++/cli 程序集并将其加载到我的 .Net 核心应用程序中的能力方面有任何进展吗？
是不是计划好了。 Net Core 3.0 发布？

@meirkr有很好的进展。 请参阅https://github.com/dotnet/coreclr/pull/22636和https://github.com/dotnet/core-setup/pull/5185。 我们正在等待的大部分是 VC++ 工具支持。 该计划适用于 .NET Core 3.0 版本。

C++/CLI 的运行时/托管工作已合并。我们现在只是在等待 VC++ 编译器/工具支持，然后才能验证端到端体验。

@jkoritzinsky ，针对 .Net 核心的新 VC++ 编译器是否能够编译旧的 C++ 运行时（例如 vc10）？
谢谢

希望我们可以用预览版 4 测试这个

@ghbeta我们已经在 VS 16.0 预览版 5 ......所以我不知道你对预览版 4 的意思;-)

从看起来你可能可以期待 VS 16.1 预览版 2 的一些东西，至少 WPF 存储库中的评论表明这是他们当前的计划（如果事情进展不顺利，这当然可能会改变，所以不要把它当作官方宣布的那样）

@fabricefou我不确定它是否能够针对旧的运行时。 我不相信它能够定位比 VS2019 MSVC++ 编译器当前可以定位的任何东西。

1.
如何追踪？
已经有目标日期了吗？

2.
是否有临时解决方法来手动配置某些内容？
我猜这里的这个活动已经使用了一些解决方案来开发和测试这个功能。 不是吗？

@ghbeta我们已经在 VS 16.0 预览版 5 ......所以我不知道你对预览版 4 的意思;-)

从看起来你可能可以期待 VS 16.1 预览版 2 的一些东西，至少 WPF 存储库中的评论表明这是他们当前的计划（如果事情进展不顺利，这当然可能会改变，所以不要把它当作官方宣布的那样）

我的意思是.net core preview 4.刚刚注意到vs16.1 preview 1到了，希望c++编译器能在preview 2上准备好，我假设我们必须将cli c++项目的框架重定向到.net core 3.0？

我们还能在 .NET Core 和 Framework 之间共享 C++CLI dll 吗？
我们希望避免生成两个 dll，每种情况一个。
有没有推荐的方法来做到这一点？

@gpetrou不幸的是，这不太可能。 面向 .NET Framework 的 C++/CLI 二进制文件将mscoree.dll作为嵌入式主机入口点。 对于 .NET Core，将使用不同的主机二进制文件- ijwhost 。

感谢您的快速回复。
如果我们必须生成两个 C++/CLI dll，我们至少可以避免生成两个引用它们的 dll 吗？
我们想使用引用 C++/CLI dll 的 .NET Standard dll（仅在 Windows 上）。 这个 .NET Standard dll 反过来可以被其他 .NET Core 或 .NET Framework 程序集引用。
那么，我们能否在 .NET Standard dll 中以某种方式决定我们需要加载哪个 C++/CLI dll？

@morganbr @Berrysoft我也喜欢在带有 Clang 或 GCC 的 Linux 机器上以及在带有 Clang 或 MSVC 的 Windows 上使用 ISO C++ 语言投影。 包装本地库以提高速度并将它们与 .Net 优点包装在一起会很摇滚。 我通常运行 HPC 代码，但有时我会用 .Net 包装它们并使用其他语言来调用它们以方便使用。 C++/CLI 是一种很好的粘合材料，但它不是可移植的，而且 ISO C++ 发展迅速，因此扩展开始显示老化。

使用 C++/CLI 的状态如何？ 16.1 预览版 2 上线了，显然 WPF 现在正在使用 dotnet/wpf#640 中的新编译器，但发行说明中没有说明如何自己使用它。

我想在 .NET Core 中试验 C++/CLI，我需要做什么才能启用它？

@weltkante

我相信最新的信息在https://github.com/dotnet/wpf/issues/607 ：

你们中的许多人可能都知道，目前不支持在 .NET Core 中构建 C++/CLI。 在 Dev16.0（又名 Visual Studio 2019）中，C++ 团队为编译面向 .NET Core 的 C++/CLI 程序集添加了有限的功能（注意：我没有写“支持”）。 有关其在 WPF 代码库中的工作原理的更多详细信息，请深入研究 Wpf.Cpp.props/Wpf.Cpp.targets 并搜索 / clr:netcore。 （如果您今天尝试使用它，由于错误，它可能对您不起作用 - 请等到 Visual Studio 2019 预览版 2 发布）。

这种对 C++/CLI 的有限支持还没有 SDK 支持。 换句话说，我们不能只采用针对 .NET Framework 的 C++/CLI vcxproj 项目并将其重定向到 .NET Core——用于发现 .NET Core 引用的底层 NuGet 支持和无数其他构建目标只是没有存在。 我们与 .NET 和 C++ 团队的几位同事合作，构建我们自己的有限支持，以在构建期间发现正确的 NuGet 引用（请参阅 Wpf.Cpp.targets 中的 CppCliHelper）

正如您所指出的，VS 16.1 预览版 2 现已发布，因此大概现在应该修复该错误。

我对这一切的发展方向感到有些困惑。 目前在 VS 16.1 Preview 3.0 中，我创建了一个 C++ 项目。 然后我可以在属性中打开 /clr 并选择一个 .NET 目标框架，比如 v4.7。 这些是像“v4.7”这样的“旧”风格名称，而不是像“net47”这样的新 SDK 名称。 在某个时候，我可以输入“netcoreapp3.0”并且一切正常吗？ 如果是这样，.vcxproj 文件会与现在大致相同还是会更改为“SDK”样式？

您已经可以将 /clr 设置为netcore ，但请注意，它的早期预览版，WPF 存储库正在道具/目标文件中配置项目并应用各种其他配置，因为还没有用于 C++/CLI 的 .NET Core 项目模板所以一切都需要明确设置。 我还没有时间让它自己运行，但如果你想自己尝试，看起来一切都在那里。

我不认为项目格式会变成“SDK”风格，从修改来看，在现有的项目系统中都可以完成。

我不明白我该如何尝试。
这是由 CLR 类库模板生成的当前命令行。
如何将其配置为指向 .net core/standard 而不是 4.7.2？

/Yu"pch.h" /GS /analyze- /W3 /Zc:wchar_t /Zi /Od /Fd"Debugvc142.pdb" /Zc:inline /fp:precise /D "WIN32" /D "_D​​EBUG" /D " _WINDLL" /D "_UNICODE" /D "UNICODE" /er rorReport:prompt /WX- /Zc:forScope /Oy- /clr /FU"C:Program Files (x86)Reference AssembliesMicrosoftFramework.NETFrameworkv4.7.2mscorlib.dll" / FU"C:Program Files (x86)Reference AssembliesMicrosoftFramework.NETFrameworkv4.7.2System.Data.dll" /FU"C:Program Files (x86)Reference AssembliesMicrosoftFramework.NETFrameworkv4.7.2System.dll" /FU"C:Program Files (x86) ) 参考 AssembliesMicrosoftFramework.NETFrameworkv4.7.2System.Xml.dll" /MDd /FC /Fa"Debug" /EHa /nologo /Fo"Debug" /Fp"DebugCoreClrCpp.pch" /di agnostics:column

@meirkr它还不是开箱即用的，它需要很多解决方法（这可能就是为什么他们甚至懒得在 VS 预览说明中提及它可以使用 C++/CLI）。 如果您知道如何阅读 vcxproj 的道具/目标，您可以查看 WPF 项目（上面我的其他答案中的链接）以查看需要哪些解决方法。 否则，最好等到他们可以在没有大量解决方法的情况下完成与 VS 的正确集成。

你能分享一个有那个 tweek 的空项目文件吗？
它可能是对项目文件的引用。

@meirkr抱歉，不，如上所述，我还没有时间让它自己运行

此外，它也不仅仅是一个简单的调整，例如构建必须配置 C/C++ 运行时并手动解析（或硬编码）所有托管程序集引用，这是一个非常大的解决方法。 WPF 项目文件创建一个虚拟项目并解析结果以解析包。 （不过，如果我要试验它，我现在可能只是对参考进行硬编码）

无论哪种方式，我认为您还不能通过简单地调整项目文件本身来使用它，您需要在构建过程中运行这些解决方法。 因此，如果您不了解它的工作原理，那么尝试它可能还为时过早。 （我确实了解链接文件中使用的大多数道具/目标，但目前没有时间在独立项目中重新实现所有解决方法。如果我有时间在 VS 获得正确集成之前设置示例项目，我会在这儿放个便条。）

我自己将 4.7.1 WPF 应用程序移植到 .NET Core 3 - 非常期待这个开箱即用的工作（即使有怪癖）。

更新：.NET 运行时端的功能工作已完成。 由于 C++ 方面的工作仍在进行中，因此完整场景尚未完成，因此我已将该问题标记为已阻止。

@jkoritzinsky
感谢您的更新 - 我想我会推迟 .NET Core 3 的移植工作。

@jkoritzinsky请提供是否有计划在.NET Core 3 下同时支持Windows 和Linux 环境中的混合模式程序集。哪些问题我们可以跟进进度

@GeorgeS2019据我所知，Linux 上没有混合模式程序集的计划，Linux 上不存在与 C++/CLI 等效的工作语言，因此提供混合模式功能没有多大意义。 当前的努力纯粹是为了在从 Desktop Framework 移植到 .NET Core 时运行某些 Windows 互操作方案。 如果您开发新代码并需要与 Linux 上的本机代码进行交互，我认为您应该使用 P/Invoke & co。

由于没有任何计划（即不会有任何进展），所以我不知道遵循 Linux 混合模式进度的问题。 如果您特别对 C++/CLI 感兴趣，那么 dotnet/runtime#4116 仍然开放，但如果没有外部贡献，可能不会很快消失。

@weltkante C++/CLI 在 Windows 上为 .NET 编译，在 Mono 上也能正常工作，即使在 Linux 上，只要您使用/clr:safe ： https :

不确定这是否是您所说的“等效工作语言”的意思，但似乎值得一提。

@SwooshyCueb这个问题是关于混合模式程序集的（不是 C++/CLI 编译到托管 IL）。 要生成混合模式程序集，您目前需要一个 C++/CLI 编译器，因为没有其他语言可以生成混合模式程序集。 当然，您可以配置 C++/CLI 以将其输入编译为不包含本机代码的 IL，但是您一开始就没有生成混合模式程序集。

@GeorgeS2019此问题所代表的支持仅与 Windows 相关。 目前没有计划在任何非 Windows 平台上支持混合模式。 与非 Windows 支持相关的问题位于https://github.com/dotnet/coreclr/issues/659。

在 Windows 上为 .NET 编译的 C++/CLI 在 Mono 上也能正常工作，即使在 Linux 上，只要您使用 / clr:safe

@SwooshyCueb绝对值得一提并要求清楚。 可以与/clr标志一起提供的各种标志使得在我们的交流中谈论这种情况需要更高的精确度。 正如@weltkante 所提到的，这个问题专门针对混合模式，根据定义，混合模式意味着同一程序

@jkoritzinsky对于 .NET Core 3.0，我们应该特别指出支持/clr标志的哪些参数。

@AaronRobinsonMSFT如果我理解正确的话，.NETCore 3.0 和 .NET5 之间的一个主要区别是 .NET 5 将支持非 Windows 的混合模式程序集，除非 MS 决定放弃非 Windows 的 C++/CLI。

对于社区来说，重要的是要知道非 Windows 的混合模式程序集已针对 .NET 5 进行了确认，并提供了预览版的估计时间表。

.NETCore 3.0 和 .NET5 之间的一个主要区别是，.NET 5 将支持非 Windows 的混合模式程序集，除非 MS 决定放弃非 Windows 的 C++/CLI。

@GeorgeS2019我认为这根本没有暗示。 .NET5 官方计划是在这里公布的，C++/CLI 没有全部提到，有没有另一篇文章提到这个？ 目前，没有计划在非 Windows 上支持 C++/CLI。 最大的原因之一是 Windows 之外的编译器支持。 我们正在问题https://github.com/dotnet/coreclr/issues/659中跟踪此请求，如果官方计划发生变化，我们将更新该请求。

我正在关注此线程，因为我对能够使用 .Net 包装本机代码以在 PowerShell 中使用感兴趣。 我认为它更有可能获得一个 C++/WinRT-ish 辅助编译器，它能够从 .Net 程序集生成 ISO C++ 头文件，以及一个匹配的模板库，它能够生成用于从 .Net 使用本机类型的代码代码。 Clang 和 GCC 也可以采用这种方法。

Kenny Kerr 曾被问及这个问题，他说 .Net 的 ABI 比受 COM 启发的 WinRT 复杂得多。 老实说，与 C++17/20 相比，C++/CLI 确实开始显示其年龄，而且辅助编译器似乎更有意义。 _（随着反射和 std::embed 在路上，所有额外的机制甚至可以在 ISO C++ 编译器中完成，但这只是一厢情愿。）_

通常：C++/CLI 所做的大部分工作都可以通过 P/Invoke 完成。 最大的不能是将两个程序集合并为一个。

如果您需要一个工具来帮助您：

• 如果您只是想从 .NET 调用 C++ 代码， SWIG是您最好的选择。
• 反之，请查看

@SamuelEnglard当然，但是 C++/CLI 的一个Point2Int32 、 RectInt32等）和实用程序类，而不必复制和混合周围的东西。

@rickbrew C++/CLI 很棒，关键是它正在做的事情没有它也可以完成，这样做只是一个主要的痛苦。 正如您所注意到的，您必须在 C++ 和 C# 中手动创建类型。

完成此问题所需的工作现在在 Microsoft C++ 编译器上进行内部跟踪。 我将暂时关闭此问题，因为 dotnet/coreclr 中的所有已知工作都已完成。

@jeffschwMSFT ：C++ 编译器是否存在任何可公开跟踪的问题？ 如果没有，我们怎么知道什么时候可以/应该尝试一下？

C++/CLI 编译器和项目系统工作与 Visual Studio 2019 计划保持一致。 添加 @tgani-msft 以帮助解决计时问题。

@jeffschwMSFT谢谢！ 时机将是很好的时间来安排未来的发布。

我们的既定目标是与 .NET Core 3 一起发布（可能支持运行时和编译器）。 我将与@tgani-msft 聊天，看看情况是否发生了变化。

C++/CLI 代码是否也与 .NET Core 3 中的 Linux 兼容？

@chriss2401 gcc 的一个分支可以做到这一点，我想

@chriss2401 gcc 的一个分支可以做到这一点，我想

谢谢回复。 所以理论上应该可以通过将“netcoreapp30”（发布时）添加到目标框架来在 Linux 上运行？ 也许@jeffschwMSFT 对此有所了解？

@SwooshyCueb您可能会混淆 C++/CLI 与混合模式程序集。 它们不一样，混合模式程序集是一种技术，而 C++/CLI 是一种语言（尽管目前是唯一可以输出混合模式程序集的语言）。 虽然 gcc 曾经有一个 C++/CLI 的实验分支，但它可能不支持混合模式，它与编译时所针对的运行时紧密绑定。

@chriss2401不，它不仅可以工作，还没有完成任何工作来支持在 Linux 上加载混合模式程序集。 （如果没有可以为其生成代码的语言，那么实现加载器就没有多大意义。这意味着语言和运行时需要共同开发，以便混合模式能够到达 Linux。）

dotnet/runtime#4116 中讨论了 Linux 上对 C++/CLI 的支持

@weltkante我不好，我在@chriss2401的评论

我们的既定目标是与 .NET Core 3 一起发布（可能支持运行时和编译器）。 我将与@tgani-msft 聊天，看看情况是否发生了变化。

@jeffschwMSFT 有任何更新吗？

@jeffschwMSFT还在等待这个功能来完成我到 .NET Core 3 的移植工作。除了 9 月发布之外还有其他日期吗？

@jgoyvaerts @jcapellman抱歉延迟回复。 关于此问题的官方博客正在制作中，一旦发布，请在此处链接。

非常感谢@AaronRobinsonMSFT！

@AaronRobinsonMSFT 有任何更新吗？

添加@tgani-msft。 @AaronRobinsonMSFT和我们的团队已经完成了这项工作的运行时/库部分。 @tgani-msft 和 C++ 编译器/工具团队正在研究何时发布此场景的调度细节。

@jeffschwMSFT感谢您的更新 - 交叉我的手指，它可以在下个月到来。

继续等待
.net core 3.1(/VS16.4) 2019 年 11 月

https://devblogs.microsoft.com/dotnet/annoucing-net-core-3-0-preview-9/

利瓦尔·库尼亚 2019-09-06 18:50:23

Tadeas Lejsek：能否请您提供有关 C++/CLI 支持的详细信息...

这是 .NET Core 3.1 和 VS 16.4 中的内容

仅供参考：相关文件更新计划。
https://github.com/dotnet/docs/issues/13152

@eightcloud83 - 我的产品的第一季度更新将包含它。 感谢您在此处发布回复。

我想分享一个关于这个的快速更新。 最新的 C++/CLI 路线图可以在我们的 C++ 博客上找到： https :

.NET Core 对 C++/CLI 的支持将在随 Visual Studio 2019 16.4 一起发布的 .NET Core 3.1 中提供。

我想分享一个关于这个的快速更新。 最新的 C++/CLI 路线图可以在我们的 C++ 博客上找到： https :

.NET Core 对 C++/CLI 的支持将在随 Visual Studio 2019 16.4 一起发布的 .NET Core 3.1 中提供。

好消息！ 我必须承认，在我看到 16.4 Preview 1 可用的那一刻，我下载了重新编译我的 C++/CLI 组件，该组件一直让我保持在 .NET 4.8 中。

我找不到使用 C++/CLI 和 .net Core 和 16.4 Preview 1 创建项目的选项。
好像需要等 16.4 Preview 2,3 ...

回复@ https://devblogs.microsoft.com/cppblog/the-future-of-cpp-cli-and-dotnet-core-3/
Will Buik 九月 25, 2019 9:57 pm
我们仍在开发 IDE 和 MSBuild 集成，因此我还不能分享示例项目。 一旦可用，可能是16.4 Preview 2 或 3 ，我们将在博客上发布更新。

16.4 预览版 2 发布。

10/15/2019
https://docs.microsoft.com/en-US/visualstudio/releases/2019/release-notes-preview#16.4.0 -pre.2.0

• C++/CLI 现在支持与 Windows 上的 .NET Core 3.1 及更高版本的互操作。
• 修复了构建面向 3.1 .NET Core 的 C++/CLI 应用程序中断的问题。

16.4 预览版 2 发布。

10/15/2019
https://docs.microsoft.com/en-US/visualstudio/releases/2019/release-notes-preview#16.4.0 -pre.2.0

16.4 预览.2,
我尝试过新的“CLR 类库 (.NetCore)”、“c++ 库针对 .net Core”，
和新的 ASP.Net Core 3 项目，尝试从 asp.net core web 调用 c++/cli 函数，
构建成功并警告..

是的！！！
如果在使用 iis expess ( @x64 windows) 时平台目标设置为“x64”，它就可以工作。
(asp.net core, c++/cli dll, iis express需要同平台)

(
（VS调试设置可以设置IIS Express Bitness，默认@x64 windows应该是64，
所以如果asp.net core平台，c++/cli dll set x86会...)
如果平台目标设置为“x86”，
”
HTTP 错误 500.0 - ANCM 进程内处理程序加载失败
”
)

预览中有一些已知问题。 一是您需要确保项目的体系结构在 C++/CLI 类库和使用它的 .NET 或 ASP.NET Core 应用程序之间完全匹配。 所以所有项目必须是 Win32/x86 或全部是 x64。 确保没有任何 .NET Core 项目在配置管理器中设置为使用“任何 CPU”。

对于 ASP.NET Core，还有一个额外要求，即它们还必须与 IIS Express 的体系结构相匹配——通常是 x64。 否则整个网站无法加载，并显示“500.0 - ANCM In-Process Handler Load Failure”。

我们正在寻找使这更顺畅的方法，但希望这可以解决这个问题。

我想试试这个，但我得到了

1>C:Program Filesdotnetsdk5.0.100-alpha1-014915SdksMicrosoft.NET.SdktargetsMicrosoft.NET.Sdk.FrameworkReferenceResolution.targets(282,5)：错误NETSDK1073：未识别FrameworkReference 'Microsoft.NETCore.App'

• 我有最新的 VS 预览更新
• 项目设置为 netcoreapp3.1（默认情况下，但无论如何验证，项目文件有<TargetFramework>netcoreapp3.1</TargetFramework> ）
• 我每晚都有最新的 dotnet 5 只是为了确保我没有遇到任何已经修复的错误

有什么办法可以防止 VS 选择错误的 SDK？

这是此时 5.0 SDK 版本的一个问题。 他们不支持定位 netcoreapp3.1。 我建议卸载它并使用 VS 附带的 3.1.100-preview SDK。

5.0 还处于早期阶段，现在分支的状态不是很好。

呵呵，有没有办法告诉VS使用哪个SDK？ 哦，好的，谢谢你的信息。 我现在开始看到一个模式，还有另一个问题，当我安装 5.0 SDK 时，我从错误的 3.0 预览中得到了一些信息。 让我想知道如果它不能并排工作，为什么它会打扰并排安装。 我希望将来可以改善体验，发布期间几个月的停机时间很烦人。 我想我现在必须忍受常规的卸载/重新安装周期（我有时正在测试只进入 5.0 分支的修复程序）

抱歉，您可以使用 global.json 告诉 VS 使用特定的 SDK。

https://docs.microsoft.com/en-us/dotnet/core/tools/global-json

哦，谢谢，那我试试看！

.net core 3.1(/VS16.4) 2019 年 11 月

.net core 3.1 已设置为 2019 年 12 月。（VS16.4 也是如此？）
（c++/cli .net core 适用于 .net core 3.1 preview1 和 VS16.4 preview2（或 VS16.3 with modifed proj setting））

这是否意味着我们可以在 .NET Core 应用程序中运行现有的 C++/CLI 程序集而无需重新编译它们？

这是否意味着我们可以在 .NET Core 应用程序中运行现有的 C++/CLI 程序集而无需重新编译它们？

现有的 C++/CLI 程序集被硬编码以初始化 .NET Framework，因此它们需要针对 .NET Core 重新编译才能正常运行。

这是否意味着我们可以在 .NET Core 应用程序中运行现有的 C++/CLI 程序集而无需重新编译它们？

好吧，我已经尝试了一些用 .NET Framework 编译的现有 C++/CLI 程序集，它们甚至可以在 .NET Core 3.0 上成功运行，但我强烈建议重新编译它们。 我认为它们可以运行在 .NET Core 上，因为 .NET Core 的兼容模式，但这并不能确保成功。

现有的 C++/CLI 程序集被硬编码以初始化 .NET Framework，因此它们需要针对 .NET Core 重新编译才能正常运行。

啊，真是令人失望:cry:

我们使用一些 3rd 方混合模式程序集，这是将我们与 .NET Framework 联系起来的唯一因素，并且供应商重新编译的可能性接近于零。

没有机会某种兼容层呢？

没有机会某种兼容层呢？

API 明智的他们可能接近兼容。 挑战在于激活。 如果程序集认为它需要激活 .NET Framework，我们无能为力。

@jeffschwMSFT如果 .NET Core 由调用者初始化会怎样？ 混合程序集会使用已经加载的内容吗？

如果 .NET Core 由调用者初始化会怎样？ 混合程序集会使用已经加载的内容吗？

C++/CLI 激活规则很复杂。 仅初始化 .NET Core 是不够的。 这些规则通常可以归结为 - 如果程序集的 dllmain 确定需要激活运行时，它将激活 .NET Framework。 没有可靠的方法来确保这一点。

出于测试目的，我们为 mscoree 提供了一个 shim 来拦截这些调用，但这并不是我们推荐的持久解决方案。

如果使用非托管导出，这是否只是一个问题，或者在托管加载期间会遇到DllMain吗？ 换句话说，如果我正确理解了该过程，导致mscoree将链加载回本机入口点的本机导入会不会？

第二个问题，如果这是 WPF 或桌面应用程序，有人会开始从本机代码调用 DLL 吗？

我的想法是，如果 C++/CLI 用于应用程序内部的本机需求，并且本机pinvokeimpl方法仅从 IL 调用，那么DllMain可能永远不会运行？

做出这些决定的是操作系统和二进制文件的组合。 有可能对这些进行建模并勉强避免 .NET Framework 的意外加载，但我建议不要这样做。 我们的建议是使用 .NET Core 重新构建 - 这样可以避免所有这些问题。
关于何时可以加载 .NET Framework（在 dllmain 中和第一次执行 p/invokes 时），您有正确的方向。

好吧，如果您没有源代码，那么值得一试 - 首先检查是否有任何本机导出超出空项目将创建的内容（数量惊人，我警告您）。 此外，如果时间仍然是男人由钢制成，船由木头制成，而不是相反，那么您可以使用dumpbin /DISASM和ildasm和/或 IL Spy 找出所有内容。

我只是尝试移植一个旧的托管 C++/CLI 项目，但是当我尝试使用它时出现BadImageFormat异常：

Unhandled exception. System.BadImageFormatException: Could not load file or assembly 'MyAssembly, Version=2019.0.1.0, Culture=neutral, PublicKeyToken=null'. An attempt was made to load a program with an incorrect format.
File name: 'MyAssembly, Version=2019.0.1.0, Culture=neutral, PublicKeyToken=null'
   at TestApp.Program.Main(String[] args)

托管程序集和测试应用程序均以 X64 为目标，我使用的是带有 .NET Core 3.1 预览版 2 的 Visual Studio Preview 16.4.0 Preview 4。构建的程序集看起来大小正确，并且 JustCompile 或 ildasm 等反编译器可以使用就好了。 我可以看到它有一个指向NETCoreApp,Version=v3.1的TargetFrameworkAttribute集。

任何想法可能是什么问题？

我们使用一些 3rd 方混合模式程序集，这是将我们与 .NET Framework 联系起来的唯一因素，并且供应商重新编译的可能性接近于零。

只是想承认，与@cocowalla一样，我们处于完全相同的位置，我们有来自第三方的混合模式程序集，它们无意更新到 .NET Core，这基本上将我们与 .NET Core 形式的死平台联系起来。 NET Framework 4.8，我们（再次）面临停滞的技术。 这是个问题。 我喜欢 .NET Core 和它里面的所有伟大的东西，但是如果我们不能在关键项目中使用它，它有什么用呢？

这基本上将我们与 .NET Framework 4.8 形式的死平台联系起来，我们（再次）陷入停滞的技术

停滞不前但死了？

“.NET Framework 4.8 将是 .NET Framework 的最后一个主要版本。如果您有正在维护的现有 .NET Framework 应用程序，则无需将这些应用程序移至 .NET Core。我们将继续提供服务和支持.NET Framework，其中包括错误、可靠性和安全性修复。它将继续随 Windows 一起提供（大部分 Windows 依赖于 .NET Framework），我们将继续改进 Visual Studio (Visual Studio) 中对 .NET 的工具支持是在 .NET Framework 上编写的。” - .NET Core 是 .NET 的未来

任何想法可能是什么问题？

@cocowalla 32/64 位不匹配？ 您确定您正在以与编译 C++/CLI 库相同的位数运行 .NET Core 应用程序吗？

@cocowalla 32/64 位不匹配？ 您确定您正在以与编译 C++/CLI 库相同的位数运行 .NET Core 应用程序吗？

不，正如我提到的，托管程序集和测试应用程序都面向 X64。 我什至确认了dumpbin /headers 😞

@cocowalla对于新问题，打开新问题可能是有意义的。 在这种情况下，您能确保 ijwhost.dll 存在吗？ 要使 .NET Core 成功激活 C++/CLI，此组件是必需的。 我们知道错误消息没有帮助，并且正在寻求改善这种体验。
默认情况下，如果您使用 VS 16.4+ 和 C++/CLI 项目构建此文件，则会自动添加此文件。

@jeffschwMSFT公平点，将打开一个新问题。 关于 ijwhost.dll，这是否意味着与运行托管 C++/CLI 程序集的应用程序位于同一目录中？

ijwhost 应该与 C++/CLI 程序集一起使用

@jeffschwMSFT 太棒了，谢谢！

ijwhost.dll 确实丢失了——它是由 C++/CLI 项目输出的，但不在测试应用程序的输出中。 现在它就在那里，它似乎起作用了！