UPDATE: COM Interop with .NET Core 2.0
The short story is that COM interop does not function in .NET Core 1.0. .NET Core is Microsoft’s open-source, cross-platform implementation of the core libraries in the .NET Framework. With its cross-platform focus, the exclusion of COM interop is intentional.
ASP.NET Core is Microsoft’s open-source web framework that sits on top of the base .NET framework. If you require COM interop and want to take advantage of new features in ASP.NET Core 1.0, you are in luck. Scott Hanselman reminds us that ASP.NET Core runs not only on .NET Core, but also on the full .NET Framework 4.6.
Here is some typical code for instantiating a COM object in C#:
dynamic myObject = Activator.CreateInstance(Type.GetTypeFromProgID("My.COMObject", true));
If you try to compile this code with .NET Core 1.0, it simply won’t work because Type.GetTypeFromProgID() is not available in the API.
That describes the current situation, but what about the future? A while back, there was actually talk about bringing pieces of COM to Mac and Linux. I think those plans have been scrapped or would only have limited use.
.NET Standard is an effort to bring a minimum common API set to all .NET platforms, present (Full Framework 4.6, .NET Core, Xamarin, Mono) and future. .NET Standard 2.0 will be implemented in .NET Core 1.1, and it brings in a lot of missing APIs from the full framework. (UPDATE: .NET Core 1.1 has been released since this was written. It includes many new APIs, but not full support for .NET Standard 2.0. That will show up in a future release of .NET Core.) It should make porting existing code to .NET Core much easier. One of the APIs slated for 2.0 (as of this writing) is Type.GetTypeFromProgID(). That means that COM interop will work on .NET Core 1.1, right? Wrong. Calling this method will throw a “Not Implemented” or “Platform Not Supported” error. As I was told by a .NET Foundation member:
There is often incorrect assumption made that “included in .NET Standard” == “works in .NET Core”. There are going to be some APIs that will throw PlaformNotSupportedException on .NET Core, also this set be different between Windows and Unix.
That’s a bit counter-intuitive to me. First of all, it seems like .NET Core should be the “reference implementation” of .NET Standard. Beyond that, the availability of APIs on unsupported platforms may lead a developer to believe an API is fully functional when it is not. To solve that issue, tooling is coming that will identify APIs that are not supported on certain platforms/runtimes (hopefully before a developer has gone through a porting effort). Also, keep in mind that a least-common-denominator approach has already been tried with Portable Class Libraries, and the .NET team is going for something better. The .NET Standard team is currently accepting feedback on GitHub, so feel free to post your thoughts and questions.
Looking beyond .NET Standard 2.0 and .NET Core 1.1, several COM/native interop pieces have already been segregated for a possible future extension. Also, the source code for the underlying functionality is readily available. I think it is only a matter of time before COM interop will be available for use with .NET Core.
6 Replies to “COM Interop with .NET Core”
This makes sense to me. Since .NET Core is supposed to be cross-platform and COM is a Windows thing, what would happen on Mac or Linux when you use Type.GetTypeFromProgID?
I agree. As I mentioned, there was previous talk about bringing COM to Mac and Linux, but they seem to have backed off that (see https://github.com/dotnet/corefx/issues/8654#issuecomment-220115997). It does make you wonder why Type.GetTypeFromProgID() is included in .NET Standard 2.0, but that could change.
For now, .NET Core is a cross-platform subset of the full framework, but it also represents the future of .NET. Hopefully, we’ll be able to use COM interop with it at some point. I would expect it to be implemented as a Windows-only extension, not as part of the core framework.
Let see if you could help me… I developed my own COM Interop dll using C# with regular .Net Framework (to be called from other programming language). It worked perfectly on Windows. But now I need it to work on Linux, so I developed it using .Net Core. It should work on Linux? If so, how can I “register” my dll on Linux?
Unfortunately, COM is a Windows-only technology. Even if COM Interop was part of .NET Core, it would not work on Linux. I don’t know much about Linux or what application communication protocols it uses. .NET Core is still new, and I don’t think it is going to provide much in this regard, but you might check with developers using Mono to see what they recommend.
Don’t use Interop anymore.. I feel happy using OpenXML is light, simple to use and doesnt have dependencies about all Office suite be installed or permissions on server.