为什么在编译和导入bits.idl时会获得额外的GUID类型定义？

Question

我正在针对COM BITS API编写一些.NET代码。我在windows kit下找到了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

你只是用IDL for BITS来解决问题，不必要的GUID类型声明只是一个小问题。 IDL从未设计为与Automation兼容，它包含太多cppquote（）用于重要声明，并使用太多非兼容类型，如LPWSTR。它只能在C ++中运行。将您从Tlbimp获得的互操作类型打造成所需的工作量，以便您可以从托管程序中使用它是非常重要的。

正如您可能猜到的，这项工作已经完成。我所知道的最好的是SharpBITS.NET library。最简单的方法是获取Nuget package。