I'm writing some .NET code against the COM BITS API. I found the bits.idl file under windows kits, and did midl bits.idl, which gave me bits.tlb. I then ran tlbimp bits.tlb and got BackgroundCopyManager.dll.
Everything is as expected in this assembly (referenced by my .net project), and shows up in the Object Browser in VS 2013, and looks good in ildasm, with one exception. I now have a new GUID type in the BackgroundCopyManager namespace, which I really don't think I want.
namespace BackgroundCopyManager
{
public struct GUID
{
public uint Data1;
public ushort Data2;
public ushort Data3;
public byte[] Data4;
}
}
I was thinking System.Guid would suffice for all my .NET-side GUID, CLSID, and IID-related needs. Can I get rid of the extra one somehow? Casting between System.Guid and this impostor isn't straightforward, and it seems like it shouldn't be necessary.
The only thing I can figure is that there are several methods in these interfaces that use GUID as a parameter type and since this idl file is from 2000 I'm guessing .NET Interop wasn't a thing yet.
You are just scratching the surface of the trouble with the IDL for BITS, the unnecessary GUID type declaration is but a minor issue. The IDL was never designed to be Automation compatible, it contains too much cppquote() for important declarations and uses too many non-compatible types like LPWSTR. It only really works from C++. The amount of work required to bang the interop types you get from Tlbimp into shape so you can use it from a managed program is substantial.
As you might guess, this work has been done. Best one I know is the SharpBITS.NET library. Easiest way to get is is by obtaining the Nuget package.