Hi Christof,

I've never thought of using a COM EXE with ASP.NET. For some reason, I didn't think it was possible, but that assumption was evidently wrong. Anyway, it does raise a couple of questions. My biggest concerns would be with resource/pool management.

Would the runtime be cached the same way a MTDLL is, or would the entire EXE have to load/unload with each hit? Does ASP.NET or IIS provide a means of limiting the number of instances loaded? You could have a pretty big problem on your hands if 100 instances managed to load. I know MTDLLs can have the same problem, but since there is only one runtime session, it is less serious.

Thanks.

>
>>I think a lot of us are curious if there are any real advantages to calling a .VFP. mtdll from a multithreaded client(such as an ISAPI exetension) as opposed to calling a .VFP. EXE COM server(pooled or otherwise) from a multithreaded client. Also in regards to actual dual or multiprocessors? What's your honest opinion??
>
>That depends on a wide variety of factors. A COM call to an EXE is slower than a COM call to another thread. I think it was a factor of 2 in the tests I did a long time ago. It depends on the actual method and the call frequency if that's really an important issue considering that a thread increases risks due to possible crashes.
>
>However, a COM call is not the only possibility to handle communication. AFP, for instance, uses named pipes instead which are faster than COM calls to communicate between the ISAPI extension and the actual server. That's the same mechanism used by ASP.NET. With such a solution the difference between MTDLL and EXE become even less an issue in terms of performance. The biggest difference is resource usage in this case. An EXE solution needs more memory as the runtime is bigger and there's copy of the runtime for each EXE.
>
>I think the reasons to pick MTDLLS over EXEs shouldn't be performance considerations, rather stability, scalability, security, etc.
>
>Christof