Yea...I've actually done a lot with the items that MS.Win32 exposes. I was just looking for the quick way out. :laugh: Thanks for your help sir.

Thanx bud...do you have a C# snippet? Doesn't have to be C# though...I'll take whatever you may have. Thanx again.

Well, I was hoping there was a programmatic way (via an API perhaps) that does it for me. It seems an oversight to me that using the COMAdminCatalog functionality will register in those locations and yet there's no converse to those actions exposed on that server. Rather dissappointing.

Thanks for all your help Heath. Much appreciated. I posted the same question on the COM list late yesterday. Our application relates to the Transportation industry. It's also a behemoth of an application with hundreds of thousands of lines of code in nearly every MS technology you can think of. Mix this in with the occasional Jr. programmer who is thrown to the wolves to a task and not very learned in thinking "outside the box", and you've got yourself a recipe for future changes that break BC. Very unfortunate, but we hit it about once a quarter. Two more questions: - Would you think purchasing Wise would bring me a faster result than building my own, even considering all the customization I'd have to do with the advanced nature of some of our installation as well as my learning curve in using the tool and a proprietary scripting language? - In your experience, are there any limitations to using Wise that would be better served by building a custom application?

Given the limitations of comercial solutions, I'm writing a custom app installation utility. I'm writing it in a generic manner. However, the application I'm initially writing it for has a mixture of .NET and ASP 3.0/COM+ functionality. As such, from managed code, I need to be able to: - Create/Delete COM+ Applications and set properties. - Register/Unregister COM+ components (unmanaged code, NOT assemblies) in those applications and set properties. I've written a class that successfully creates applications and adds components. However, when using COMAdminCatalog.InstallComponent() to register and add components to the application it adds exactly 18 entries to the registry. By contrast, simply registering a component and its type library from the commandline using regsvr32 adds only 10. My Issue: Using either COMAdminCatalog.Remove() or resvr32 /u doesn't remove ALL registry entries, but leaves 6 entries, all under HKLM\SOFTWARE\Microsoft\COM3\SelfReg. The entries left in there include a CLSID, ProgID and type library. My Question: I've searched the .NET fx high and low and looked for options for interop, all to no avail. How do I programmatically remove ALL references of a COM+ DLL from the registry so as not to cause any potential conflicts (DLL hell) in future upgrades where binary compatibility is broken? Thanx! Boyd Campbell Systems Engineer

Ok...I'll make another post of the original message on the COM list. FYI: The server was actually registered in another method using the COMAdminCatalog: lobj_Catalog.InstallComponent("MyCOMPlusApplication", @"c:\myUnmanagedComSErver.dll", "", ""); If you can point me in any direction or give any recommendations on how to create my own installation package, I'd appreciate it. If you have any opinions about InstallShield, Wise or any other third party tool, I'd appreciate that as well. We decided to go in-house because those tools don't handle some of the more complex issues concerning enterprise application installation (COM apps & servers & all related settings, MSMQ & settings, any other custom functional aspects of the install, etc.). Thank you sir!

Sorry...I thought I made it clear, though I should've used the word "unmanaged". I am talking about a native COM+ server. However, I'm having to do it from managed code (C#), so I believe I'm in the proper messageboard context. Here's a snippet I whipped up as an example of what I'm attempting to accomplish: public static void DeleteComServicesApp() { // Get the current catalog of applications. COMAdminCatalog lobj_Catalog = new COMAdminCatalogClass(); COMAdminCatalogCollection lobj_Catalogs = (COMAdminCatalogCollection) lobj_Catalog.GetCollection("Applications"); try { lobj_Catalogs.Populate(); // Try to find the applicable application. if(lobj_Catalogs.Count > 0) { ICatalogObject lobj_AppToFind; bool lb_Exists = false; for(short i = 0; i < lobj_Catalogs.Count; i ++) { lobj_AppToFind = (ICatalogObject)lobj_Catalogs.get_Item(i); if((string)lobj_AppToFind.get_Value("Name") == "MyCOMPlusApplicationToDelete") { /* The application was found. Delete it, thereby removing and unregistering all unmanaged COM+ servers in the process. Though the application is properly removed from the catalog, this is what I'm saying doesn't fully unregister the servers. It removes many of the registry entries, but not all. */ lobj_Catalogs.Remove(i); lobj_Catalogs.SaveChanges(); lb_Exists = true; break; } } } } catch (MyCustomCatalogException cce) . . .

Given the limitations of comercial solutions, I'm writing a custom app installation utility. I'm writing it in a generic manner. However, the application I'm initially writing it for has a mixture of .NET and ASP 3.0/COM+ functionality. As such, I need to be able to: - Create/Delete COM+ Applications and set properties. - Register/Unregister COM+ components (NOT assemblies) in those applications and set properties. I've written a class that successfully creates applications and adds components. However, using COMAdminCatalog.InstallComponent() to add components to the application adds exactly 18 entries to the registry. By contrast, simply registering a component and its type library using regsvr32 adds only 10. My Issue: Using either COMAdminCatalog.Remove() or resvr32 /u doesn't remove ALL registry entries, but leaves 6 entries, all under HKLM\SOFTWARE\Microsoft\COM3\SelfReg. The entries left in there include a CLSID, ProgID and type library. My Question: I've searched the .NET fx high and low and looked for options for interop, all to no avail. How do I programmatically remove ALL references of a COM+ DLL from the registry so as not to cause any potential conflicts (DLL hell) in future upgrades where binary compatibility is broken? Thanx! Boyd Campbell Systems Engineer