To date, I've been totaly removing any server registry keys by completely removing the registy key. However, this passage taken from a MS doc says different:
When an application wishes to remove the component from the system, it should unregister that component by calling DllUnregisterServer. Within this call, the server removes exactly those entries it previously created in DllRegisterServer. The server should not blindly remove all entries for its classes because other software may have stored additional entries, such as a TreatAs key.

My question is what is this key? How likely is it to be somehow added to my server class key? What other additions might i expect out of the blue, in this fashion? (Or is this just MS covering all bases, and it never really happens?)

Posted on 2004-06-04 16:20:27 by NaN
Greetings Nan,
Excerpted from Eddon's Inside COM+:
Posted on 2004-06-04 19:48:24 by Poimander
I still dont get why this should be preserved. I mean, even this 'treatAs' key would have to be added when the DLL is registered. Thus you should be able to safely remove it when unregistering..

If you have a class you create, and you want it to be 'teated as' a specific type of class, you would be adding it to some other registry entry, or making up your new 'treat as' indirect key. Thus, since your removing your class as an option you would be required to remove the class from 'treat as' entries made through out the system too....

Im just trying to find a reason to preserve the registry entries for your DLL. I like things clean and would prefer to leave nothing lingering if i can. This means removing all things related to the DLL (including the folder entry to the registry)....

In my minds eye, the only thing that should put anything in registry keys made by registering your COM dll is the REGSVR32.EXE it self... And on this line of thought, it should be able to equally remove all things added (start with nothing, clean up to nothing..)

Please if you can, proove to me that im wrong or overlooking something.
Posted on 2004-06-04 20:56:02 by NaN
As far as I understand it the situation is
somewhat simplified in the sense that you need only be
concerned with one such 'TreatAs' registry key per
category, namely ...
Posted on 2004-06-04 22:14:54 by Poimander
Hi NaN,

if I understand this correctly, MS assumes that another server has inserted the treatas entry and thus in fact taken your CLSID, since now the new server (the CLSID in the treatas value) is responsible for your CLSID. So MS may be right with its advise. But this case seems rather unlikely for CLSIDs we create.

Posted on 2004-06-05 03:03:17 by japheth
Thats how im seing this... Seems somewhat unpractical. I would rather keep a clean registry than worry about the 'what-if' case that will probably never happen... (as i understand it).

Posted on 2004-06-05 13:17:51 by NaN

if I look in my registry many "treatas" entries are by MS office applications. the 32bit version of Excel for example has taken over the old 16bit excel CLSID. If the 16bit version behaves as MS tells us it should it can be unregistered and any old 16bit VB app trying to start excel will still work.
Posted on 2004-06-06 03:37:29 by japheth