0

我正在针对COM BITS API编写一些 .NET 代码。我在 windows kits 下找到了 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 还不是一个东西。

4

1 回答 1

1

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

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

于 2015-03-03T16:12:29.487 回答