>I don't call SetComplete or SetAbort from the test component. Although I tried with both of them from another component and the unload of my dll was just as random as without them. Do I need to call either of these functions if I mark my component as "Does not support transactions" in MTS? (just for tests purposes, of course, because, in fact, we need transactions.)

If you use MTS without those you're keeping state in yuor components
and you may as well not call MTS...

>At this moment I want to have a sure way to unload the dll, just to make my development environment easier and faster. (If the dll is hold by MTS/IIS, I cannot overwrite it, etc.)

You can't. MTS manages your DLL. If you're running straight IIS (no MTS)
IIS manages it. MTS caches DLLs as it sees fit. Even when the ref
count goes to 0 it'll keep things around (I thnik the default is 3 minutes).
I wouldn't count on the total unload to work either - many things
in MTS don't work as advertised.

The idea is once your object is loaded you loose control over it
for managing it.

>
>>IIS *never* releases any InProc servers. However, MTS should. Test it
>>from VFP to make sure that MTS is doing things right before messing
>>with IIS...
>
>This is something I don't understand. As far as I read until now, MTS creates the objects. Why do they "live" in IIS's process?

But IIS holds a reference to the MTX and which in turn knows that it's
ref'ing your COM object.

>
>Why do I need to involve VFP here? The components are written in VC++.
>

So you can test away from the skewed IIS environment. IIS behaves different
than other COM clients because it does extra caching.

>>Why are you bothering with MTS anyway? Worthless for scalability...
>
>Well, I'm not very sure MTS is usefull for this project. :) But my boss and other two members in the team want to use MTS really bad :) and it's not my decision right now. Our BOs must work in MTS and that's all. :) In the mean time, I understand that MTS makes things easier for transaction management. Is this wrong?

Yes, it's useful for transactions if htey span multiple databases.

I say that MTS incurs a lot of overhead on COM objects managed by it
and unless you really need the *features* (not scalability features)
MTS is currently not a good choice, IMHO.

Make sure you COM object works correctly by calling it directly from
VFP - you should see the correct load/unload behavior with the
constructors and destructors firing as you load and unload your
object.

Then go back and try with MTS.

+++ Rick ---