>I can understand the frustration. Assuming that the object's interface hasn't changed, if it's still getting whacked, then solving the problem would seem to require your feared solution. Even in the case of a change of exposed PEMs, simply updating the type library should be all that's required.
>
>While my experience doesn't include WC and COM, it does include the creation of a number of servers. In testing, I've never bothered to un-register/re-register one, just simply copy the files over the old ones.

In fact, in my case, the "interface" does change at times as new functionality is built in. But as long as you build the EXE from the same VFP Project, the Registry class Id's are maintained. Sort of like using Binary Compatibility in VB. You can then just copy the new EXE over the old one and you're good to go. WC provides for us to do this operation on-the-fly.

And in my case I did check the vbr file for the class ID's and compared them to the various entries in the Registry of my production server and all looks consistent. So I have to conclude that there is some other mechanism at work here to whack my COM servers. I'm just really do not know what steps to take at this point to track it down. If it is a MS/IIS/COM issue, there may/probably not be anything I can do about it anyway. :-)