Post-installation problem
-
I have a strange problem that shows up after I install our software. By "our software" I mean one of my company's products. I'll try to keep this short enough to read and will happily supply any further details. The product is written in C# targeting .NET 2.0. It consists of three components. Two are installed as Windows services, the third is a WinForm based GUI. Only one of the services is involved in the problem, hereafter referred to as the "Server." The GUI application is the other involved, hereafter referred to as the "Client." Both the Client and the Server need to use a third party native DLL, which is installed in the System directory (C:\WINDOWS\system32.) We are hoping to use Windows .msi installer packages, which I'm producing using VS2005. The installers register the DLL mentioned as "vsdrfCOMSelfReg" and that seems to work. The problem comes in if we install both the Server and the Client on the same computer. Normally our customers will have one Server installed and multiple Clients on different machines as you would expect. However it's possible, even likely, that someone will install a Client on the Server machine. That causes the Server to lose its ability to perform the function for which it uses the DLL. In our previous versions of this product, we used installers built by another tool, Setup Factory 7.0 from Indigo Rose. I have found that if I use SF7 installer for the Client, I don't have the problem. That's our interim solution until I figure out what's the problem with the .msi installer. Here's what I've tried so far. Remove all components of this product from the machine, and delete anything left behind by the uninstallers (Registry entries, log files, etc.) Take a snapshot of the file system and of the HKLM Registry hive. Run a Client installer. Take another snapshot of the file system and of the HKLM Registry hive. Compare these snapshots to see what files are installed and what's added to the Registry. Remove Client and clean up after uninstall. Repeat procedure with the other Client installer. Compare results from each type of installer. The SF7 installer puts some files it uses for uninstalling in the installation directory and in C:\WINDOWS. Other than that, no difference. The .msi installer puts a whole bunch of stuff about itself in the Registry. Both install all the expected files and make the same Registry entries regarding registering the DLL. At long last, the questions: Any ideas what might be causing this? What else should I try
-
I have a strange problem that shows up after I install our software. By "our software" I mean one of my company's products. I'll try to keep this short enough to read and will happily supply any further details. The product is written in C# targeting .NET 2.0. It consists of three components. Two are installed as Windows services, the third is a WinForm based GUI. Only one of the services is involved in the problem, hereafter referred to as the "Server." The GUI application is the other involved, hereafter referred to as the "Client." Both the Client and the Server need to use a third party native DLL, which is installed in the System directory (C:\WINDOWS\system32.) We are hoping to use Windows .msi installer packages, which I'm producing using VS2005. The installers register the DLL mentioned as "vsdrfCOMSelfReg" and that seems to work. The problem comes in if we install both the Server and the Client on the same computer. Normally our customers will have one Server installed and multiple Clients on different machines as you would expect. However it's possible, even likely, that someone will install a Client on the Server machine. That causes the Server to lose its ability to perform the function for which it uses the DLL. In our previous versions of this product, we used installers built by another tool, Setup Factory 7.0 from Indigo Rose. I have found that if I use SF7 installer for the Client, I don't have the problem. That's our interim solution until I figure out what's the problem with the .msi installer. Here's what I've tried so far. Remove all components of this product from the machine, and delete anything left behind by the uninstallers (Registry entries, log files, etc.) Take a snapshot of the file system and of the HKLM Registry hive. Run a Client installer. Take another snapshot of the file system and of the HKLM Registry hive. Compare these snapshots to see what files are installed and what's added to the Registry. Remove Client and clean up after uninstall. Repeat procedure with the other Client installer. Compare results from each type of installer. The SF7 installer puts some files it uses for uninstalling in the installation directory and in C:\WINDOWS. Other than that, no difference. The .msi installer puts a whole bunch of stuff about itself in the Registry. Both install all the expected files and make the same Registry entries regarding registering the DLL. At long last, the questions: Any ideas what might be causing this? What else should I try
Have you enabled MSI logging? if not, read how to http://support.microsoft.com/kb/223300[^] then investigate the resulting log files. Use Systems Internals Process Monitor (or RegMon + FileMon) to record activity at installation and look for any Access Denied and investigate those. Keep us posted on your progress
-
Have you enabled MSI logging? if not, read how to http://support.microsoft.com/kb/223300[^] then investigate the resulting log files. Use Systems Internals Process Monitor (or RegMon + FileMon) to record activity at installation and look for any Access Denied and investigate those. Keep us posted on your progress
I'll try the MSI logging. I've got Process Monitor, I'll need to look at it more closely to see how to accomplish what you describe. So far I've not seen anything missing in either the files or Registry, as I assume would be the case if an Access Denied situation arose. Thank you for the reply, I'll get busy with your suggestions. :)
BDF A learned fool is more a fool than an ignorant fool. -- Moliere
-
I'll try the MSI logging. I've got Process Monitor, I'll need to look at it more closely to see how to accomplish what you describe. So far I've not seen anything missing in either the files or Registry, as I assume would be the case if an Access Denied situation arose. Thank you for the reply, I'll get busy with your suggestions. :)
BDF A learned fool is more a fool than an ignorant fool. -- Moliere
-
I have a strange problem that shows up after I install our software. By "our software" I mean one of my company's products. I'll try to keep this short enough to read and will happily supply any further details. The product is written in C# targeting .NET 2.0. It consists of three components. Two are installed as Windows services, the third is a WinForm based GUI. Only one of the services is involved in the problem, hereafter referred to as the "Server." The GUI application is the other involved, hereafter referred to as the "Client." Both the Client and the Server need to use a third party native DLL, which is installed in the System directory (C:\WINDOWS\system32.) We are hoping to use Windows .msi installer packages, which I'm producing using VS2005. The installers register the DLL mentioned as "vsdrfCOMSelfReg" and that seems to work. The problem comes in if we install both the Server and the Client on the same computer. Normally our customers will have one Server installed and multiple Clients on different machines as you would expect. However it's possible, even likely, that someone will install a Client on the Server machine. That causes the Server to lose its ability to perform the function for which it uses the DLL. In our previous versions of this product, we used installers built by another tool, Setup Factory 7.0 from Indigo Rose. I have found that if I use SF7 installer for the Client, I don't have the problem. That's our interim solution until I figure out what's the problem with the .msi installer. Here's what I've tried so far. Remove all components of this product from the machine, and delete anything left behind by the uninstallers (Registry entries, log files, etc.) Take a snapshot of the file system and of the HKLM Registry hive. Run a Client installer. Take another snapshot of the file system and of the HKLM Registry hive. Compare these snapshots to see what files are installed and what's added to the Registry. Remove Client and clean up after uninstall. Repeat procedure with the other Client installer. Compare results from each type of installer. The SF7 installer puts some files it uses for uninstalling in the installation directory and in C:\WINDOWS. Other than that, no difference. The .msi installer puts a whole bunch of stuff about itself in the Registry. Both install all the expected files and make the same Registry entries regarding registering the DLL. At long last, the questions: Any ideas what might be causing this? What else should I try
Right, I think your problem here is most likely to be that the file has different GUIDs in the different installers. Windows Installer tracks 'components', not files. It determines whether a component is installed or not by checking the KeyPath of the component - this is the file, registry key, directory or ODBC data source which it uses to determine whether the component is up to date. Visual Studio generates one component per file or registry key. You can get into serious trouble if the same file is referenced by more than one component GUID on the machine. For each component installed by a product, Windows Installer remembers the key path that the component was installed to. When the number of references for a component in a given location drops to zero (the actual references are recorded, not the count, so it's more like GC than reference counting), all the resources for that component are removed, even if another component is still referencing the resource. To avoid this problem, you must either: install the component privately, or if that isn't possible, ensure that the same GUID is used in both products. I believe the only way to get VS to do this is to build a merge module containing the shared component, and consume that merge module in both installers. Now for some more fun: although you've told it to self-register at install time, Visual Studio also tries to extract the registry information at install package build time, and uses the extracted data to populate the Class table[^] and the other associate COM tables. This causes Windows Installer to generate special registry entries when installing the class, an extra load of gibberish in a REG_MULTI_SZ value called LocalServer32 in the LocalServer32 key. This data tells Windows to give Windows Installer control when the object is created; Windows Installer checks whether the component is installed and if it needs to be repaired. If so you'll get a repair dialog. If the version numbers are different between client and server, this may happen; if it can't find the original installer, it may prompt for source. Again, I think this can be reduced by ensuring the GUIDs are the same. If you don't need to support Windows Installer's enterprise features, it may be easier all around if you use a tool that does not build Windows Installer databases. It's much much
-
Right, I think your problem here is most likely to be that the file has different GUIDs in the different installers. Windows Installer tracks 'components', not files. It determines whether a component is installed or not by checking the KeyPath of the component - this is the file, registry key, directory or ODBC data source which it uses to determine whether the component is up to date. Visual Studio generates one component per file or registry key. You can get into serious trouble if the same file is referenced by more than one component GUID on the machine. For each component installed by a product, Windows Installer remembers the key path that the component was installed to. When the number of references for a component in a given location drops to zero (the actual references are recorded, not the count, so it's more like GC than reference counting), all the resources for that component are removed, even if another component is still referencing the resource. To avoid this problem, you must either: install the component privately, or if that isn't possible, ensure that the same GUID is used in both products. I believe the only way to get VS to do this is to build a merge module containing the shared component, and consume that merge module in both installers. Now for some more fun: although you've told it to self-register at install time, Visual Studio also tries to extract the registry information at install package build time, and uses the extracted data to populate the Class table[^] and the other associate COM tables. This causes Windows Installer to generate special registry entries when installing the class, an extra load of gibberish in a REG_MULTI_SZ value called LocalServer32 in the LocalServer32 key. This data tells Windows to give Windows Installer control when the object is created; Windows Installer checks whether the component is installed and if it needs to be repaired. If so you'll get a repair dialog. If the version numbers are different between client and server, this may happen; if it can't find the original installer, it may prompt for source. Again, I think this can be reduced by ensuring the GUIDs are the same. If you don't need to support Windows Installer's enterprise features, it may be easier all around if you use a tool that does not build Windows Installer databases. It's much much
Thank you so much for that detailed reply. As this is not our most pressing issue and we have an interim solution, I'll be waiting until my new book arrives in the mail before exploring further. I'd like to attempt the merge module approach, which I'll try after studying the book a bit. I thought it would be better to have MSI installers but it might be more trouble than it's worth. It's always nice to have options though. Thanks again, Mike. Once again I'm humbled by how much I don't know. :)
BDF A learned fool is more a fool than an ignorant fool. -- Moliere
-
After you have created the MSI file, you could use this utility to look at the contents of the MSI to establish if the MSI file has expected contents etc. Less MSIérables[^]
Thanks for the link. I downloaded and used it. Didn't find anything other than what I expected to be in the MSI package. It will be a handy tool to have around. Need to make time to look at the source code. Today I ran the installer with logging on and Process Monitor running. Examined the log file and the Process Monitor data but did not find any errors of note or anything else relevant to the problem. However Mike Dimmick posted a reply that I believe contains the answer and some possible solutions. It's quite detailed if you're interested. It turns out that two MSI installers installing the same DLL in the same directory is not as straightforward an operation as I had expected. Thanks again for your help. I learned a lot from the exercise. :)
BDF A learned fool is more a fool than an ignorant fool. -- Moliere
-
Thanks for the link. I downloaded and used it. Didn't find anything other than what I expected to be in the MSI package. It will be a handy tool to have around. Need to make time to look at the source code. Today I ran the installer with logging on and Process Monitor running. Examined the log file and the Process Monitor data but did not find any errors of note or anything else relevant to the problem. However Mike Dimmick posted a reply that I believe contains the answer and some possible solutions. It's quite detailed if you're interested. It turns out that two MSI installers installing the same DLL in the same directory is not as straightforward an operation as I had expected. Thanks again for your help. I learned a lot from the exercise. :)
BDF A learned fool is more a fool than an ignorant fool. -- Moliere
-
Thank you so much for that detailed reply. As this is not our most pressing issue and we have an interim solution, I'll be waiting until my new book arrives in the mail before exploring further. I'd like to attempt the merge module approach, which I'll try after studying the book a bit. I thought it would be better to have MSI installers but it might be more trouble than it's worth. It's always nice to have options though. Thanks again, Mike. Once again I'm humbled by how much I don't know. :)
BDF A learned fool is more a fool than an ignorant fool. -- Moliere
Big Daddy Farang wrote:
I thought it would be better to have MSI installers but it might be more trouble than it's worth.
That's been my experience with MSI as well. Lots of headaches for zero benefit. I will never use it for a project if I have a say in the matter.
--Mike-- Visual C++ MVP :cool: LINKS~! CP SearchBar v3.0 | C++ Forum FAQ "That's what's great about doing user interface work. No matter what you do, people will say that what you did was idiotic." -- Raymond Chen