I was doing some maintenance today on my Web site and noticed that on my local machine I had problems with some Web pages that are using VFP COM components. Since I move between machines a bit these days I had initially forgotten to register the COM components on my local box. Quick fix I thought – but…

As it turns out it looks like there are some COM issues in IIS 7 (on Vista Beta 2) that cause at least Visual FoxPro COM objects to fail. I’ve not been able to get these objects to run and even creating the simplest component caused the server to completely crash with a 500 Server error. As soon as a VFP COM object gets instantiated either in ASP.NET or ASP Classic – boom the server crashes completely and only an IIS Reset is getting it back…

I spent a bit of time trying to get to the bottom of this but ended up with no luck. It’s not permissions (gave the server full access) and it’s not the COM object itself since the object works fine standalone and even with the VS internal Web Server. Incidentally for ASP.NET at least the workaround for the moment is to use the built in Web Server for development at least as that will properly run the COM object. However, that doesn’t work for ASP classic pages…

I also tried sticking the component into COM+ with the same result.

I’m just thankful that Web Connection and its internal ISAPI COM manager works on IIS 7 without any problems and I don’t have to come up with a temporary workaround just to run my WWWC applications. I’m sure the above issue will be addressed or may already be fixed in later releases of IIS, but only shows that you can’t take even core functionality like COM access for granted.

VFP COM Object in ASP.NET 2.0 Projects

Incidentally I haven’t touched COM and ASP.NET COM components since I’ve worked with ASP.NET 2.0. There are few issues with the new project model and how it handles COM components that is very different than in 1.1. Specifically, I think there are going to be problems for ASP.NET applications that change the VFP COM objects and need to refresh the Interop assembly. In an ASP.NET 1.x project the Interop assembly automatically refreshed itself when the project was recompiled, but this no longer happens in 2.0 stock projects. Stock projects do a one time import and that’s that. You change the COM object, you have to reimport the COM object.This makes and already painful process even more annoying…

There’s a workaround for this however: You can create a standard Class Library project and add the reference of the COM object that this project. Class projects still refresh COM objects properly, so when you recompile a class project it tries to pick up the changes in the COM object and updates the Interop assembly. You then add the separate project to your Web project and the Interop assembly comes down with it automatically and now a recompile of either project causes the Interop assembly to be refreshed.

When I get some time I should spend a little more time with this to review what has effectively changed. But it’s getting harder and harder to justify any sort of COM interop… <s>