.NET 6中COMReference的EmbedInteropTypes相关技术问询

背景说明 #

我们的.NET 6应用通过csproj文件中的<COMReference>使用Excel Interop，当前配置EmbedInteropTypes="true"，会将所需互操作类型子集嵌入程序集。若将其设为false，MSBuild会将若干.NET Framework程序集复制到bin目录，这些程序集引用GAC中的stdole和Microsoft.Vbe.Interop。

疑问1：这些.NET 4、.NET 2（Vbe）、.NET 1（stdole）程序集在.NET 6 Windows应用中使用是否安全？本地测试正常，但担心在其他环境不稳定。 #

在Windows环境下是安全的。.NET 6及后续的.NET Core系版本支持**.NET Framework兼容性模式**，CLR会自动处理旧版程序集的加载逻辑，只要目标系统是Windows，且安装了对应版本的Office组件，就不会有稳定性问题。需要注意的是：

• 要保证用户系统的Office版本和你开发时依赖的Interop版本匹配
• 这类旧版互操作程序集仅支持Windows，不要在Linux、macOS等非Windows环境下使用

疑问2：安装了当前Windows系统和Office的用户，其GAC中是否会存在这些程序集？是否需要随应用分发stdole和Vbe程序集？ #

（考虑禁用嵌入的原因：混淆工具合并含嵌入互操作类型的程序集时会破坏这些类型）

• stdole：这是.NET Framework的核心组件，几乎所有现代Windows系统都预装了.NET Framework，因此用户GAC中必然存在该程序集，完全不需要随应用分发。
• Microsoft.Vbe.Interop：该程序集是Office安装时自动部署到GAC的，只要用户安装了对应版本的Office（默认安装会包含VBA相关组件），GAC中就会有这个程序集，同样不需要分发，强行分发反而可能引发版本冲突。
• 另外，禁用EmbedInteropTypes后，MSBuild复制到bin目录的是Excel Interop的包装程序集（如Microsoft.Office.Interop.Excel.dll），这类程序集可以随应用一起分发，它们仅作为COM组件的调用包装，不会依赖本地未安装的.NET Framework组件。

疑问3：为何嵌入的互操作类型对引用包含该类型的程序集的其他程序集不可见？是否有办法使其对外可用？ #

嵌入的互操作类型本质是将COM类型的元数据内联到当前程序集中，并且默认标记为internal（仅内部可见），所以其他程序集无法访问——这是嵌入机制的设计初衷，目的是让使用互操作的程序集可以独立运行，无需依赖外部的Interop程序集。

没有直接的方法让嵌入的类型对外可用，这违背了该机制的设计目标。如果需要让其他程序集也能使用这些互操作类型，只能选择以下两种方案：

• 禁用EmbedInteropTypes，将对应的Interop程序集作为独立依赖，提供给所有需要的程序集引用
• 自行封装一层对外公开的API，内部使用嵌入的互操作类型，通过封装的接口向外暴露功能

内容的提问来源于stack exchange，提问作者Rob