COM Interop with .NET Core

Logo_DotNet

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.

References:

Thoughts on Metro and the Windows Runtime

Like many developers, I spent much of last week and the weekend watching the Microsoft BUILD conference and learning about Windows 8, the new Metro UI, and the Windows Runtime (WinRT).  My first impression of the Metro interface was that it is compelling and I like it.  That has faded a bit as I get into the details of what you can and cannot do with the new architecture.  There is a lot to like about the Metro user and developer experiences, all of which you can learn about at Microsoft and the blogosphere.  As a developer, I’m thinking along the lines of how I can use the new technology while preserving my investment in existing code and skills.  Restrictions built into Metro (by design) have a direct impact on that.  While highlighting all the cool new stuff, Microsoft has glossed over the restrictions a bit, so this post looks at things from that point of view.  First of all, I should say that this is a developer preview, Microsoft is looking for feedback from developers on their design decisions, and some of those decisions may change before release.

The more I learn about Metro/WinRT, the more I realize it is “Windows” in name only.  To start, there are no windows in Metro!  Everything is full screen.  While there are some things shared under the hood (like the Windows Kernel and file system), for the most part, Metro is separate and isolated from the Windows “desktop”.  Metro competes directly with Apple iOS and Google Android in the tablet space, while also being available to PCs. That much is obvious, but being bundled in Windows, you might think you also get access to all the goodness in the Win32 and .NET APIs.  That is not the case.  This really is two operating systems in one box.

So, why not just sell Metro separately as a new OS?  Microsoft already tried that. It’s called Windows Phone 7, and nobody’s buying.  Even Windows Vista had 400 million users, so bundling Metro with Windows ensures there is a viable market for apps.  Besides, we developers would freak out if Microsoft dropped Windows for something entirely new.  Putting Metro in Windows is good all around.

A key point to make is that Metro is client-side technology only.  In spite of support for HTML, these are desktop apps.  The HTML is not served up by a server, but rather is compiled into the Metro app.  Being client-side technology, there are a lot of things Metro doesn’t do.  Microsoft expects your business logic and database access to be done on the server and exposed as a service that Metro apps can consume.  Of course, they would be happy to host this service for you in Azure, but that is not a requirement.

How about the Windows Runtime?  What exactly is it?  It could have just as easily been called the Metro Runtime, because it exists for the sole purpose of servicing Metro apps.  Under the covers, WinRT components are written in native C++ (take that Dev Div!), and interfaces are exposed using COM and metadata.  This does not mean that COM is making a comeback in Metro.  Microsoft has used COM (specifically the IUnknown interface) for years as a means of exposing native interfaces, and they are simply using that rather than reinventing the wheel.  There are no type libraries, rather interfaces are described in a modified version of the .NET metadata format called winmd.

So, if you’re thinking about accessing the WinRT from FoxPro or other environment using COM, you can forget about that.  In fact, this whole notion of automating other applications is absent from Metro.  You cannot directly start another application and communicate with it from Metro.  This applies to both Metro and desktop apps.  You can send info to another Metro app via “contracts”, such as the Share contract in Metro.  But you can only use contracts provided by Microsoft, and these contracts can only be initiated by the user, not in code.  If you do need to communicate with another app, even on the same machine, then you’ll need to use network protocols, such as IP sockets, http, or web services.

With all this hype, what is Metro replacing?  Something has to die, right?  I’m sure each of us will draw our own conclusions on that, but I will say that Microsoft always emphasizes the shiny new thing.  That doesn’t mean existing MS technologies will go away, or that MS will stop investing in those technologies.  At the same time, Microsoft is clearly investing heavily in Metro and will continue to do so, at least until the next shiny new thing comes along.  From a technical point of view, to the extent that you can port your code (based on restrictions) and that you choose to adopt the Metro design, Metro replaces almost everything.  If every desktop app were rewritten in Metro, then it could even replace Windows as a whole.  It’s hard to know what Microsoft’s aspirations are in this regard, but based on the targeted nature of Metro and its capabilities, I don’t see this happening, not for a long, long time, if ever.  From the point of view of each technology…

.NET: I can unequivocally say that the .NET Framework is here to stay.  Since Metro is only client-side technology, you will need something on the server side, and Microsoft will continue to push .NET for that.  When building C#/VB apps, Metro does use the .NET Framework, however it restricts you to a subset of functionality.  For example, you cannot use the System.Data namespace, which means no ADO.NET, which means you can’t access a database directly from Metro.  You’ll need to build the data access into the server side using .NET.  For what it’s worth, I believe Silverlight has the same restriction.  Microsoft seems to be deciding what the .NET restrictions are based in part on what they did in Silverlight (more on that topic at http://channel9.msdn.com/events/BUILD/BUILD2011/TOOL-930C).  Lastly, do I even need to mention ASP.NET?  Browser-based web apps aren’t going anywhere.

Silverlight/WPF: As far as being deprecated, I worry about Silverlight the most.  MS will be pushing Metro on the desktop and HTML5 through the browser.  Some will say that WPF is already dead.  On the other hand, PhotoShop was shown at the keynote and given as an example of an app that would NOT be appropriate for Metro, due to its dense UI design with a focus on productivity.  Many line-of-business applications could be described in the same way, so there is still a place for these technologies.  As it stands, there are new versions coming out for both, but beyond the next version, we don’t know.  Now that the XAML group is part of Windows, Metro will no doubt get the lion’s share of the resources, but I hope investment continues on Silverlight and WPF.

Win32/C++:  For the most part, C++ developers will be using WinRT in Metro rather than the Win32 API.  MS does allow access to a subset of Win32 APIs that have functionality not addressed in WinRT (http://msdn.microsoft.com/en-us/library/windows/apps/br205757%28v=VS.85%29.aspx), but at this level, WinRT and Win32 really are separate worlds.  That said, Win32 is the most used API on the planet. Even if MS doesn’t invest another cent into it, it will be here a long time.

Let’s talk about preserving your existing investments.  Microsoft is focused on making sure your existing skills can be used when building Metro apps.  That is, as long as those skills include HTML/JS, C#/VB, or C++.  You might even be able to port existing code into Metro, but it’s not copy and paste, and it has to adhere to the restrictions.  Microsoft demoed porting existing XAML and code from Silverlight and Windows Phone apps that were already written in the MVVM pattern used by Metro.  If you want to move from a Windows Forms UI, I doubt there is much you can keep, and you’ll be rewriting the UI in Metro.  From FoxPro, you don’t get to keep anything, except what you use on the server side.  I’m not a C++ developer, but I imagine porting C++ code would involve replacing Win32 calls with WinRT functionality. I don’t know how feasible that is, so you may be able to bring in code that doesn’t reference Win32 (good luck finding some) and rewrite the rest to use WinRT.

As far as compiled libraries, you can’t just add a reference to a .NET DLL in a Metro app.  You can, however, create a “Portable Library” that can be called from both Metro and standard .NET, as long as the library sticks to the Metro subset of .NET.  I don’t know how this works in C++, but it may be the same story.  MS showed bringing the Boost library into a Metro app, but I don’t know if that was Boost source code or a compiled library.

Moving on to user interface… Microsoft is providing developers with clear design guidelines for Metro apps.  Designers may not like being told how to design their apps, but I don’t think it is a requirement that you follow the Microsoft rules.  Personally, I am glad that Microsoft is providing guidance on Metro design, because we got no such guidance with WPF or Silverlight.  How many times have you seen WPF or Silverlight session where the speaker says “I’m not a designer…”, and then proceeds to show a crappy looking UI that makes you wonder why you would want to use the technology at all? With Metro, I can use the MS templates, follow the guidelines, and end up with an attractive, functional app.  If I want to do something extra special, then I can get a professional designer involved.

What about deployment of Metro apps? You will be able to use “side-loading” to test and debug your apps on a limited number of devices.  Otherwise, you can’t directly install your Metro app on a device.  It must be deployed through the online Windows Store.  Each app you upload will be certified against a series of tests to ensure compatibility and compliance.  So, if you’re thinking about using some tricks to get around the restrictions I’ve already mentioned, that may work on your machine, but the certification tests will fail and you won’t be able to deploy your app.  Microsoft hasn’t released details yet, but most expect they will do the same as the Windows Phone store and take 30% of the price of Metro apps.  You may have heard that the store will be free, but I believe that is only for the listing of Windows desktop (non-Metro) apps, in which case, MS just links to your site, but doesn’t handle deployment.  There will also be an enterprise deployment option for companies that want to deploy apps internally.  Apple charges $299/year so that you can distribute code YOU write to devices YOU purchased.  That’s not a lot of money, but it just rubs me the wrong way, so we’ll see what Microsoft does in this regard.

So, Microsoft has Metro locked down pretty tight.  Metro limits you to a subset of .NET. You can’t automate other applications or reference existing “desktop” DLLs.  MS forces you to deploy through their store and takes 30% off the top.  This is not characteristic of the Microsoft we have worked with all these years, but they are following Apple’s lead.   At the same time, by exerting this level of control, Microsoft can ensure the integrity, stability, and security of the Metro experience.   The restrictions prevent outside code from polluting and compromising the Metro environment.  If that all seems a little too Big Brother to you, you still have the option of creating Windows desktop and HTML applications without the restrictions, both of which can still be touch enabled.

With all of this in mind, should you run out and rewrite all of your applications for Metro?  Every day, I work on a FoxPro line-of-business app with a heavy emphasis on data entry and productivity.  The fact that we’re still using FoxPro should tell you that we don’t jump at every new technology that comes out of Microsoft.  But, even if this were a WPF or Silverlight app, I don’t think it would be a good candidate for the Metro style.  Maybe that’s a lack of imagination on my part, but displaying info one screen at a time or with a bunch of panning or scrolling would cause a large hit to productivity.  Now, are there pieces of our app that I could expose to a wider audience using a simpler interface with touch capabilities?  Yes.  And the developer and user experience in Metro is compelling enough that I might just target it over an HTML interface that works on multiple devices.  I’m looking at Metro as an environment where I can offer new apps and experiences to users when it makes sense, not as a replacement for existing technologies.

C# 4.0 Gets dynamic

I’ve been watching some of the PDC 2008 videos online.  One of the highlights is The Future of C# by Anders Hejlsberg, and I highly recommend it to anyone that’s interested in .NET.  Most of the session focuses on the dynamic capabilities that are coming to C# 4.0.  The .NET Common Language Runtime (CLR) was built primarily with static typing (aka “strong typing”) in mind, in which every variable must be explicitly declared and assigned a type (string, integer, etc.).  Microsoft recently built the Dynamic Language Runtime (DLR) to support dynamic (non-static) languages, such as Python and Ruby, and they are using the DLR to bring some dynamic features to C#.

To you strong-typing zealots, there’s no need to be alarmed.  C# is not transforming itself from a static to a dynamic language.  There is a gap between static and dynamic languages, and the focus is on closing that gap and improving the interaction.  It just so happens that FoxPro is a dynamic language…

To illustrate the problem, here is a simple VFP class I wrote that finds a customer and creates an object for the customer using Scatter:

Define Class Customers As Session OlePublic

oCustomer = NULL

Procedure GetCustomer(lcCustomerID As String)
Local loCustomer

If !Used("Customers")
 Select 0
 Use (Home(2) + "Northwind\Customers")
Else
 Select Customers
EndIf
Locate For CustomerID = lcCustomerID
Scatter Name This.oCustomer Memo

EndProc

Procedure Destroy

Use In Select("Customers")

Endproc

Enddefine

I compiled the class into a COM DLL and imported it into my C# project.  (For more on that, see Rick Strahl’s article: .NET Interop for VFP Applications.)  Since This.oCustomer is created dynamically at runtime, FoxPro cannot include it in the type library.  Therefore, to access any properties of the oCustomer in C#, you have to use “reflection”.  Here’s the C# code:

string CustomerID = "ALFKI";
netcomtest.Customers oCustomers = new netcomtest.Customers();

oCustomers.GetCustomer(CustomerID);
object oCust = oCustomers.OCUSTOMER;
//use reflection to access object properties
object CompanyName = oCust.GetType().InvokeMember("COMPANYNAME", BindingFlags.GetProperty, null, oCust, null);
object ContactName = oCust.GetType().InvokeMember("CONTACTNAME", BindingFlags.GetProperty, null, oCust, null);
//display company and contact name
MessageBox.Show(CompanyName.ToString() + ContactName.ToString());

What a mess!  If I wanted to access all of the properties on the object, this would get very tedious.  C# 4.0 makes the process easier by introducing a new “dynamic” type.  This tells C# to resolve the type of the variable at runtime (just like Fox would), rather than at compile time.  If I understand Anders correctly, here’s what the new code should look like :

string CustomerID = "ALFKI";
netcomtest.Customers oCustomers = new netcomtest.Customers();

oCustomers.GetCustomer(CustomerID);
//create dynamic reference to object
dynamic oCust = oCustomers.OCUSTOMER;
//display company and contact name
MessageBox.Show(oCust.CompanyName + oCust.ContactName);

Now, isn’t that better?  I can actually understand this code.  I can access all the properties of oCust directly, just like I would in FoxPro.  It’s nice to see that COM Interop is one of the things that Microsoft is still improving.

Anders also showed some things they are working on beyond C# 4.0.  Fast forward to the 60 minute mark in the video to see the cutting-edge stuff they are working on.  In short, they are rewriting the compiler, so they can do stuff like put code into a string variable and evaluate/execute it at runtime.  Fantastic!  Anders took it a step further and showed C# commands being executed as he entered them into a window.  Unbelievable!  It’s amazing what they can do these days!  Seriously, should you find yourself working with C# in the future, it will be nice to have some capabilities we’ve grown to love in VFP.