使用Excel Interop部分属性时.NET Framework项目编译卡顿问题咨询

出现编译挂起的核心原因是Excel Interop的COM互操作类型处理和DLLExport的IL重写机制在编译阶段发生冲突：

1. Excel Interop的属性（比如Workbooks.Count）本质是COM对象的getter方法，编译时需要解析COM类型信息；而DLLExport需要在编译后修改程序集IL以生成非托管导出入口，两者的处理逻辑在编译器进程中出现资源竞争或死循环。
2. 默认开启的「嵌入互操作类型（Embed Interop Types）」会把COM类型的精简信息嵌入程序集，DLLExport在处理这些嵌入类型时容易触发解析异常，导致编译器卡住。

1. 禁用嵌入互操作类型 #

右键项目中引用的Microsoft.Office.Interop.Excel，打开属性面板，将Embed Interop Types设置为False。
这样编译时会使用完整的互操作程序集，避免嵌入类型带来的IL解析冲突。

2. 用反射绕开编译时属性绑定 #

在导出方法中，不要直接访问xlWorkbooks.Count，改用反射获取属性值：

using System.Reflection;
using Microsoft.Office.Interop.Excel;

public static string TestExcelCompile()
{
    Application ExcelApp = (Application)Marshal.GetActiveObject("Excel.Application");
    Workbooks xlWorkbooks = ExcelApp.Workbooks;
    
    // 用反射获取Count属性值
    int WbCount = (int)xlWorkbooks.GetType().GetProperty("Count").GetValue(xlWorkbooks);

    return "";
}

这种方式把属性解析延迟到运行时，避免编译阶段的类型绑定冲突。

3. 拆分Excel操作与导出逻辑 #

把所有Excel互操作代码放到一个不使用DLLExport的单独类库项目中，然后让带DLLExport的主项目引用这个类库。主项目的导出方法只负责调用类库中的逻辑，不直接处理COM对象：

// 单独类库中的代码（无DLLExport）
public class ExcelHelper
{
    public static int GetWorkbookCount()
    {
        Application ExcelApp = (Application)Marshal.GetActiveObject("Excel.Application");
        return ExcelApp.Workbooks.Count;
    }
}

// 带DLLExport的主项目代码
public static string TestExcelCompile()
{
    int WbCount = ExcelHelper.GetWorkbookCount();
    return "";
}

这种方式隔离了DLLExport的IL处理和COM互操作的编译逻辑，从根源避免冲突。

4. 更新DLLExport到最新版本 #

部分旧版DLLExport对.NET Framework 4.8和COM互操作的兼容性较差，尝试更新到项目的最新版本，可能已经修复了这类编译冲突问题。

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