Claude,

We disagree of course.

>VFP mtdlls are not "free-threaded" and I don't think anybody ever claimed they were. Free-threading, like what's available in .NET, is probably more efficient, but also more dangerous.

Ah, but you're missing the point (again). The fact when you actually use STA threads affects the performance of the entire ASP.NET AppDomain, becuase ASP.NET has to manage those STA threads differently than the rest of the ASP.NET Threads. It also means that you're still stuck in this model where

Is that really a problem? It depends. Performance is pretty good, but under heavy load an STA style thread has a lot more overhead and requires state that can easily get corrupted. It frequently blocks as it must ensure that the COM object gets called the same thread it was created on for succesive calls. Compared to ASP classic which was optimized for STA style COM objects, ASP.NET fares much worse, because it's optimized for MTA threads.

I'm not sure what you mean by 'more dangerous'. The multi-threading in ASP.NET is handled by the system so there's no more danger to it than any oterh way. If anything STA threads are much more complex as they must marshall resources between calls to make sure that a server created on one thread always gets called on that same thread. There are significant resources and potential blocking scenarios involved in this. You as the developer don't see either of these directly as ASP.NET just hands you your main request thread. But the mechanics underneath vary widely and have very different performance characteristics.

> The slight performance hit you describe will probably never be noticeable to anyone when calling a vfp mtdll from ASP.NET(see http://www.activevfp.com/avfpdemo2/default.aspx). I think your own performance tests actually showed VFP mtdlls performing better when called from ASP.NET in COM+. In fact, at this point, VFP mtdlls are the best we can do with VFP and multithreading things like web apps, so, why attack it??

The performance difference between ASP classic and ASP.NET with VFP COM objects is fairly significant regardless of whether you run COM+ or not. THat in addition to the lack of direct type access of complex VFP objects (or dynamically generated objects that VFP cannot return a type lib entry for) are two things that make VFP a pain to work with in this scenario.

This is not an issue with a simple COM interface. If you have a one level object that has no child objects or no dynamically generated objects you will not have to deal with the operational issues. If you have an engine (like your's I suppose) that has a simple entry point for one method that does all - sure that works fine.

But then you're not taking advantage of anything ASP.NET really has to offer. The 'official' scenario for using ASP.NET with VFP is to build using ASP.NET as a UI front end with a Fox business layer. And *that* is a PITA with ASP.NET, because VFP cannot create a decent type library with nested objects and objects returned from methods. For this reason it's actually easier to use ASP classic because it isn't hindered by this strong typing requirement.

I've given presentations on this stuff in many places and talked to a large number of developers who have already gone done that path and believe me that the verdict on this is not a good one. The basic concepts are easy enough to deal with, but the devil is in the details!

ASP.NET + VFP is not a good choice for a *strategic application*, IMHO. Your mixing two technologies that don't particularily work well together. It works in that you can make it work, but give up most of the goodness and advantages of ASP.NET in the process.

Use VFP *or* .NET. But both together is a transitional band-aid, not a good choice for strategic systems! Anybody who does both together is very likely to dump VFP (or .NET) because it's just so much easier to work with a single environment!

+++ Rick ---


>>>Sorry, for most intents and purposes vfp multi-threaded dlls(mtdlls) are indeed multithreaded(thus the name). Multiple threads are running at the same time. The technology behind it doesn't really matter as far as this is concerned...
>>
>>Oh, but it does!
>>
>>In fact, if you don't understand how this works you can get into serious trouble very quickly.
>>
>>For example, try setting up an ASP.NET page without setting ASPCOMPAT="true" and you can see just how multi-threaded a VFP COM object is. Without ASPCOMPAT ASP.NET will create your VFP COM object on a true freethreaded (MTA) thread and your objects will blow up at worst or do all sorts of crazy stuff when they are running simultaneously at best.
>>
>>MTDLLs are a simulation of multi-threading and really the COM system provides this for you. VFP can play by STA rules. It's important to understand this with ASP.NET for example. The STA imposition on VFP MTDLLs in fact is one of the reasons why ASP.NET is much slower in calling VFP COM objects than classic ASP was for example.
>>
>>It works, but it's important that one understands what's actually happens behind the scenes lest you get into trouble and not have any idea why things are going wrong...
>>
>>+++ Rick ---