This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: COM Automation Interface unregistered after uninstall
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 09, 2008
12:22 PM
COM Automation Interface unregistered after uninstall
So I'm trying to automate our build process and I've written a small program in C# (Visual Studio 2008) that interfaces with the automation library. To deploy that solution, I created a small setup project in Visual Studio 2008. It detects all the dependencies, packages it and creates an MSI. So after the program is installed and working fine and I decide to uninstall it, the COM registration for the automation interface disappears. I have to repair the InstallShield installation to get it back. Is there a work around/fix for this?
(2) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 09, 2008
12:35 PM
Sure, don't use VDPROJ!
Sersiously, VDPROJ has this annoying way of detecting dependencies that you don't need detected. It grabs a copy of the automation library, drops it in a private location and registers it and then on uninstall whacks it killing the original registration ( god COM sucks... ) You can try opening the VDPROJ solution and `exclude` the dependency and if you build locally that'll work but I've also seen alot of times where if you build the solution on another machine it'll redetect the depenency for you.
I would just get rid of VDPROJ and and make an InstallShield Basic MSI to deploy your utility. When you add your assembly as a component, set the .NET scan to Properties Only.
Sersiously, VDPROJ has this annoying way of detecting dependencies that you don't need detected. It grabs a copy of the automation library, drops it in a private location and registers it and then on uninstall whacks it killing the original registration ( god COM sucks... ) You can try opening the VDPROJ solution and `exclude` the dependency and if you build locally that'll work but I've also seen alot of times where if you build the solution on another machine it'll redetect the depenency for you.
I would just get rid of VDPROJ and and make an InstallShield Basic MSI to deploy your utility. When you add your assembly as a component, set the .NET scan to Properties Only.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 09, 2008
02:51 PM
Yeah, it is kind of dumb. So, per your suggestion I looked at the properties for the dependencies in the setup project. It turns out that the type library files are set to be registered when installed, which I find stupid since they were already registered by InstallShield. So, I set each type library to not be registered and everything works great now.