I was surprised to find out that COM Interop works in .NET Core when running on Windows. It's possible to access COM components via Reflection easily enough in .NET Core 2.x. Unfortunately use of the `dynamic` keyword does not work in .NET Core 2.x so for the moment COM interop is limited to using Reflection.

When it comes to deploying STA COM components in ASP.NET only WebForms has native support for STA component. Other technologies like MVC, ASMX Web Services and WCF run only in MTA mode. If you need to run your STA COM Components in ASP.NET here is what you need to know and a few tools that help you create STA compatible handlers.

If you've ever run into the Unable to cast Transparent Proxy to error, you know how frustrating it can be. Usually this is caused by multiple assemblies causing unexpected load behaviors. Here's what the problem is and how you can check for problems.

Registrationless COM makes it possible to run COM components without registry configuration making for an xCopy deployable solution. The process is not terribly difficult but not easy to debug if something goes wrong. Here's how you can use registrationless COM in your apps.

Ran into an interesting issue today with binary data passed from COM to .NET via a dynamic instance. The result was rather unexpected with dynamic failing to properly cast the binary to byte[] or even a basic object instance.

When moving applications to 64 bit servers be sure to check that you don't call old school, 32 bit COM objects. If you do these COM object calls fail. Thankfully IIS 7 and later allows Application Pool configuration to enable 32 bit operation to work around this issue. Here's how.

The addition of the new dynamic typing in the .NET runtime greatly simplifies COM Interop when passing FoxPro objects to .NET. Dynamic types remove the need to use explicit Reflection on dynamically generated FoxPro types that are returned over COM interop and so reduce code complexity and produce more natural and readable code removing one of the annoyances in FoxPro and .NET COM Interop.

If you're using the Web Browser Control or the Internet.Application Shell object, you might need to call Javacript t code inside the pages loaded in the browser to manipulate the page from say a WinForms app that interacts with the Web Browser control. Some things are just much easier to do with client side script code and being able to initiate this code from .NET can be very useful. This entry describes how you can access the DOM to call script functions both in .NET and FoxPro.

I'm calling a COM object from managed code that's returning a binary response, which is returned as a SafeArray of bytes from the COM server. The problem is the SafeArray is not exactly easily accessed in .NET and the debugger provides some misleading information for the returned COM type. Here's how to access the SafeArray from C# code.

Note to self: Remember that the COM RegEx parser doesn't deal with the . operator the same way in multi-line content as .NET or most other RegEx parsers do. I've just spent 20 minutes troubleshooting a RegEx expression that works just fine in RegEx Buddy and .NET code, but failed in one of my...

I'm working on an old app that interfaces with a legacy COM object. In reviewing some of my wwDataBinder code I noticed that it didn't work against COM objects for databinding. With a few minor changes I've been able to make the binding code work by using the the higher level Type.InvokeMember...

COM Interop is rarely fun, but it looks like it's getting to be less and less useful as time goes on and new .NET Runtime features come along that don't work well over COM. It appears that Generic types can't be exported over COM and be usable to a client like Visual FoxPro. When I create a class...

Interop with .NET from FoxPro can be accomplished fairly easily by using COM Interop. With COM Interop you can take advantage of .NET's COM Callable Wrapper to wrap up .NET components and make them available as COM objects. I've written extensively about this interaction (here and here)...

I'm still screwing around Web Connection and trying out a quick proof of concept tonight and thought I'd share a few steps on how to host a WCF in a non .NET client via COM Interop client like Visual FoxPro. This article discusses WCF server and client creation in general terms and in addition covers the interop issues to make it work in these clients.

Recently I built an HttpHandler to replace my ISAPI interface for Web Connection, which is an application interface that provides Web connectivity to Visual FoxPro. The ISAPI extension has been working fine for many years, however with the advent of IIS 7 I figured it's time to create a more...

I just had a little brain freeze dealing with HRESULT error from a COMException. When dealing with COM objects you still need to deal with the unfortunate COM idiosyncrasies like HRESULT values which get returned from just about every COM call. COMException exposes this HRESULT as an int value. Now...