Installer woes
-
I'm having some inconsistency problems with my deployment project ("Setup") and its custom actions ("Installer"). I'm using Visual Studio .NET 2003 (.NET 1.1, no service pack) on Windows XPSP1. My main project is a band object (Explorer Bar) in an assembly (.DLL) that needs to be registered on installation and unregisted on uninstallation. In addition, during installation, Setup creates registry subkeys, sets registry values, installs some application files, and adds a new file-type. On uninstallation, Setup is supposed to undo all of that. More specifically, I have custom actions for Setup that are run within the Installer class. The Installer class is within the main assembly, and perhaps surprisingly, that seems to work, some of the time. I have also tried putting the Installer class in its own assembly, both as a class library and as a console application, and that doesn't seem to work any better than having the Installer class in the main assembly. Sometimes the registration or unregistration of the main assembly fails. The workaround we tell our users (a small userbase so far, fortunately) is to "repair" after installation, or to uninstall completely before installing a new version. Neither are as ideal as being able to simply install over the previous version. I think there are two subproblems. 1) The Uninstall custom action in the Installer class isn't always called. This is especially inconsistent. My Installer class overrides OnBeforeUninstall() [so that the main assembly is unregistered before the files are removed] and Uninstall() [so that savedState is empty, in order for the installState to be removed]. Lacking better debugging tools for MSIs, I added code in these methods to set registry entries containing the timestamp at the beginning and end of each of these methods. I verified that usually the Uninstall custom action is (but not always) called when the user explicitly asks to remove the package (via "Add/Remove Programs"), but when the user is installing over a previous version, sometimes (but not always) the Uninstall custom action is called. As a side note, I change the installer version, PackageCode, and ProductCode whenever I build a new installer. I don't understand why these inconsistencies occur. For a while I thought VS.NET might randomly corrupt the Setup.vdproj file and that I'd have to remove and add the custom actions again, in order to be sure that the Uninstall custom action was registered, and once or twice I built the Setup.vdproj file from scratch,
-
I'm having some inconsistency problems with my deployment project ("Setup") and its custom actions ("Installer"). I'm using Visual Studio .NET 2003 (.NET 1.1, no service pack) on Windows XPSP1. My main project is a band object (Explorer Bar) in an assembly (.DLL) that needs to be registered on installation and unregisted on uninstallation. In addition, during installation, Setup creates registry subkeys, sets registry values, installs some application files, and adds a new file-type. On uninstallation, Setup is supposed to undo all of that. More specifically, I have custom actions for Setup that are run within the Installer class. The Installer class is within the main assembly, and perhaps surprisingly, that seems to work, some of the time. I have also tried putting the Installer class in its own assembly, both as a class library and as a console application, and that doesn't seem to work any better than having the Installer class in the main assembly. Sometimes the registration or unregistration of the main assembly fails. The workaround we tell our users (a small userbase so far, fortunately) is to "repair" after installation, or to uninstall completely before installing a new version. Neither are as ideal as being able to simply install over the previous version. I think there are two subproblems. 1) The Uninstall custom action in the Installer class isn't always called. This is especially inconsistent. My Installer class overrides OnBeforeUninstall() [so that the main assembly is unregistered before the files are removed] and Uninstall() [so that savedState is empty, in order for the installState to be removed]. Lacking better debugging tools for MSIs, I added code in these methods to set registry entries containing the timestamp at the beginning and end of each of these methods. I verified that usually the Uninstall custom action is (but not always) called when the user explicitly asks to remove the package (via "Add/Remove Programs"), but when the user is installing over a previous version, sometimes (but not always) the Uninstall custom action is called. As a side note, I change the installer version, PackageCode, and ProductCode whenever I build a new installer. I don't understand why these inconsistencies occur. For a while I thought VS.NET might randomly corrupt the Setup.vdproj file and that I'd have to remove and add the custom actions again, in order to be sure that the Uninstall custom action was registered, and once or twice I built the Setup.vdproj file from scratch,
This is not much help. I've had problems with running custom actions on uninstall as well and I have not yet resolved them. One thing you can do to at least try to get some more information is to create a full log file of the installer actions. Run your msi package from the command line using the following verbose logging command line options and it will generate a complete log. Unfortunately, interpreting the log is another matter, and acting upon that interpretation still another ... :-( But it is a starting point at least. Typical command line is: msiexec.exe /L*v "C:\MySetup.log" /I "C:\MySetup.msi" i.e. msiexec.exe /L*v /I Good Luck! Robert
-
This is not much help. I've had problems with running custom actions on uninstall as well and I have not yet resolved them. One thing you can do to at least try to get some more information is to create a full log file of the installer actions. Run your msi package from the command line using the following verbose logging command line options and it will generate a complete log. Unfortunately, interpreting the log is another matter, and acting upon that interpretation still another ... :-( But it is a starting point at least. Typical command line is: msiexec.exe /L*v "C:\MySetup.log" /I "C:\MySetup.msi" i.e. msiexec.exe /L*v /I Good Luck! Robert
Thanks for your reply! I have been looking at the full log file off and on for several months, and I don't see anything in there explaining my problems, especially why the Uninstall custom action sometimes doesn't run.
-
This is not much help. I've had problems with running custom actions on uninstall as well and I have not yet resolved them. One thing you can do to at least try to get some more information is to create a full log file of the installer actions. Run your msi package from the command line using the following verbose logging command line options and it will generate a complete log. Unfortunately, interpreting the log is another matter, and acting upon that interpretation still another ... :-( But it is a starting point at least. Typical command line is: msiexec.exe /L*v "C:\MySetup.log" /I "C:\MySetup.msi" i.e. msiexec.exe /L*v /I Good Luck! Robert
Do you think our deployment projects have anything in common besides the obvious (.NET, etc.)? Is there some way we could work together on solving this?
-
Do you think our deployment projects have anything in common besides the obvious (.NET, etc.)? Is there some way we could work together on solving this?
Actually mine was very simple. I'm sure you've seen the MSDN walkthroughs on how to create a custom action to compile NET assemblies into Native Images on the target machine. Well when that happens it adds an entry for each native image into a system table (you can view the list with ngen /L command I think.) All I was trying to accomplish was creating a "well behaved setup" that would remove any Native Image entries it created using the Uninstall event. It was a while back and I don't really remember much. I do remember that it should have been simple, but I never got it to work, and got tired of messing with it. :-) I came to the conclusion that the Installer class worked fine for Install actions, but because I had problems getting even a simple uninstall action to run, I pretty much decided to abandon using them. I think that until I can afford to get InstallShield, I'll go with creating a C++ dll to run any sort custom actions and just manually edit the Action tables in the msi to make sure my uninstall action calls in a DLL are made during an uninstall before the dll itself is removed. There are some other things I don't like about the msi packages created with the NET IDE anyway, so I've devoted more time to learning about manually creating entire installs using Orca rather than digging any further into the Installer class. Sorry ... Robert
-
Actually mine was very simple. I'm sure you've seen the MSDN walkthroughs on how to create a custom action to compile NET assemblies into Native Images on the target machine. Well when that happens it adds an entry for each native image into a system table (you can view the list with ngen /L command I think.) All I was trying to accomplish was creating a "well behaved setup" that would remove any Native Image entries it created using the Uninstall event. It was a while back and I don't really remember much. I do remember that it should have been simple, but I never got it to work, and got tired of messing with it. :-) I came to the conclusion that the Installer class worked fine for Install actions, but because I had problems getting even a simple uninstall action to run, I pretty much decided to abandon using them. I think that until I can afford to get InstallShield, I'll go with creating a C++ dll to run any sort custom actions and just manually edit the Action tables in the msi to make sure my uninstall action calls in a DLL are made during an uninstall before the dll itself is removed. There are some other things I don't like about the msi packages created with the NET IDE anyway, so I've devoted more time to learning about manually creating entire installs using Orca rather than digging any further into the Installer class. Sorry ... Robert
Ah, okay. Well, I think most of my critical woes are gone now. I was trying to register assemblies in a custom action, and that was a bad idea, so I let the MSI handle the registration. I still notice that the MSI doesn't seem to delete some registry entries that it added, and perhaps sometimes the Uninstall custom action isn't called, but that's more of a matter of tidying up the registry than something critical. (I try to clean up the Registry after myself, but it's not my fault if the MSI sometimes can't be bothered to do it.) Thanks! Arun
-
Ah, okay. Well, I think most of my critical woes are gone now. I was trying to register assemblies in a custom action, and that was a bad idea, so I let the MSI handle the registration. I still notice that the MSI doesn't seem to delete some registry entries that it added, and perhaps sometimes the Uninstall custom action isn't called, but that's more of a matter of tidying up the registry than something critical. (I try to clean up the Registry after myself, but it's not my fault if the MSI sometimes can't be bothered to do it.) Thanks! Arun
Yes. I try for clean uninstalls, but at some point sometimes you have to just let it go. I've never seen a Microsoft product itself that said it was logo certified???? And some of their setups are pretty bad. When they released the eval versions of SQL Server 2000, I got one and put it on my machine. It ruined my MSDE server, and I had to go in and do massive manual registry cleanups to get MSDE installed back on my machine and working properly. Now I do registry backups before I install anything from Microsoft, LOL. Robert
-
Yes. I try for clean uninstalls, but at some point sometimes you have to just let it go. I've never seen a Microsoft product itself that said it was logo certified???? And some of their setups are pretty bad. When they released the eval versions of SQL Server 2000, I got one and put it on my machine. It ruined my MSDE server, and I had to go in and do massive manual registry cleanups to get MSDE installed back on my machine and working properly. Now I do registry backups before I install anything from Microsoft, LOL. Robert
Pretty funny stuff! Sad but true...