为什么编译导入时多了一个GUID类型定义bits.idl？

Question

我正在针对 COM BITS API 编写一些 .NET 代码。我在 windows 套件下找到了 bits.idl 文件，并做了 midl bits.idl，这给了我 bits.tlb。然后我运行 tlbimp bits.tlb 得到了 BackgroundCopyManager.dll.

此程序集中的一切都符合预期（由我的 .net 项目引用），并显示在 VS 2013 的对象浏览器中，并且在 ildasm 中看起来不错，只有一个例外。我现在在 BackgroundCopyManager 命名空间中有一个新的 GUID 类型，我真的不认为我想要它。

namespace BackgroundCopyManager
{
    public struct GUID
    {
        public uint Data1;
        public ushort Data2;
        public ushort Data3;
        public byte[] Data4;
    }
}

我认为 System.Guid 足以满足我所有的 .NET 端 GUID、CLSID 和 IID 相关需求。我能以某种方式摆脱多余的吗？在 System.Guid 和这个冒名顶替者之间进行转换并不简单，而且似乎没有必要。

我唯一能想到的是，这些接口中有几种方法使用 GUID 作为参数类型，而且由于这个 idl 文件来自 2000 年，我猜 .NET Interop 还不是一个东西。

Answer 1

您只是触及了 BITS 的 IDL 问题的表面，不必要的 GUID 类型声明只是一个小问题。 IDL 从未设计为与自动化兼容，它包含太多用于重要声明的 cppquote() 并使用了太多不兼容的类型，如 LPWSTR。它只适用于 C++。将您从 Tlbimp 获得的互操作类型调整为形状以便您可以从托管程序中使用它所需的工作量是巨大的。

如您所料，这项工作已经完成。我知道的最好的是 SharpBITS.NET library. Easiest way to get is is by obtaining the Nuget package.

为什么编译导入时多了一个GUID类型定义bits.idl？

Why do I get an extra GUID type definition when compiling and importing bits.idl?

com-interop

midl

tlbimp