Rick,
Cool! Thanks for doing this. Yeah, it should be only one centralized method call from C# (just like we do from ASP) and the TLBIMP process can be automated. I expect performance to get even better with time as MS tweaks this whole area more...
>>I think we should start doing some performance tests before we start concluding there are performance problems with ASP.NET(C#) to VFP mtdlls. Early binding should actually make it faster, not, slower than even ASP to vfp mtdll which is already incredibly fast. Also, in the area of debugging, I'm working on putting together a "file-based" stub (just like wwc) that will allow you to step thru code and then switch to the VFP mtdll for ultimate performance...
>
>I did in fact just now as I'm putting together a document on VFP/ASP.NET COM operation. It looks like ASP.NET COM access is about 20% slower than classic ASP. More so if you use COM+ components.
>
>This of course is mostly call overhead, so if you have methods that do a lot of work then this overhead is not an issue. However, if a lot of COM method calls are made this overhead percentage gets much worse.
>
>Definitely slower.
>
>Early binding doesn't help .NET much - the slowness comes from the thunking from managed code into unmanaged code.
>
>Still, performance isn't terrible. Testing a simple VFP counter object (from the old ASP article) yields about 75 requests a second, while classic ASP runs closer to 100 requests a second about 115 with COM+ component.
>
>There are other issues that make ASP.NET a lot more fussy than for COM use. For one the only realistic way to get objects into .NET is to do a TLBIMP on the COM object which can be a PITA if you build both the VFP and ASP.NET apps at the same time - everytime a change is made to the interface you'll have to re-run the TLBIMP (or let VS.NET do it for you) but it's not automatic. I guess one can build a ProjectHook to do this.
>
>The other major problem is that you can't pass back generic objects at least not to C#, because of type issues. You can only return types that are in the type library, which means *everything* in your app that returns an object has to be exposed as a COM object, which can be problematic.
>
>Overall, it's obvious that COM support is backwards compatibility feature, not a feature meant to spur new development...
>
>+++ Rick ---