Runtime: Registration-Free COM Interop and .Net Core 2.0

[Evmaus-MS]

So we have an application (BinSkim, which is here: https://github.com/Microsoft/binskim ) that we're porting to .net core which relies on COM Interop with msdia140.dll to enable some features on Windows.

We've run into an issue where if the .dll is present by the application, but unregistered, we get exceptions about COM classes being unregistered when we use the COM Interop.

However, if we register the the .dll (e.x. by executing 'regsvr32 msdia140.dll'), the interop works fine! Normal/Vanilla .NET also works as expected here (the COM interop works as expected), but we're trying to ship a Linux version (with some features that require COM/Windows interop disabled), and that means shipping a .net core version that has some platform specific feature flags (so from my perspective I'd rather we ship entirely .net core).

In short--Is this expected?

We've got a tracking issue here, and I'm available to help with a repro if it isn't expected: https://github.com/Microsoft/binskim/issues/173

[danmosemsft]

@jeffschwMSFT

[jeffschwMSFT]

We've run into an issue where if the .dll is present by the application, but unregistered, we get exceptions about COM classes being unregistered when we use the COM Interop.

We are adding reg-free COM support in .NET Core 3.0. Check out https://github.com/dotnet/core-setup/issues/4314 for status.

if we register the the .dll (e.x. by executing 'regsvr32 msdia140.dll'), the interop works fine!

This is good to hear, we are expanding our Windows COM support in .NET Core 3.0 to make this even more seamless.

shipping a .net core version that has some platform specific feature flags

This is a common scenario for our customers. You can support this by either recompiling per platforms with if defines, or doing runtime checks by platform.

cc @AaronRobinsonMSFT @luqunl

[AaronRobinsonMSFT]

@Evmaus-MS As @jeffschwMSFT mentioned this is definitely something we are looking at for 3.0 and please follow the referenced issue for RegFree COM support. I have extensive experience working with DIA and it doesn't really require COM at all, that is a historic artifact of the implementation. If this is really blocking and you have already done the work to ship the DLL app local, I would recommend P/Invoking into msdia140.dll and calling DllGetClassObject() directly. There is no need to initialize the COM apartment since DIA doesn't really need it anyways.

The above approach is how many tools in Visual Studio load DIA now that Visual Studio has switch over to having less install impact and RegFree COM can be rather annoying. If you are at all interested in this approach feel free to contact me via email and I can provide an example.

[Evmaus-MS]

@jeffschwMSFT OK, thanks--that clears up the behavior we were seeing.

@AaronRobinsonMSFT Thanks for the suggestion--we wound up going this route, and are now able to ship 100% .NET Core.

Since our question was answered & we found a workaround, I've closed this issue.