I have an program that used to uninstall properly and remove ALL files associated with it during uninstall. We have revamped our install/uninstall process to now use installshield.
With the previous install/uninstall process it was working just fine until about 2 weeks before we changes it, and still even now with he new installshield installers it fails to remove the .dll files upon uninstall.
I don't think the problem is with the installers themselves because we have the same exact problem with 2 very different methods.
Currently to make the uninstall process work we use control panel to uninstall it then delete the remaining .dll files manually
This problem happens to all the machines with these components and it is happening with all the components.
All machines had problems start at the same time.
with my installshield process i have verbose logging output to a .txt file, I do not know how would be best to display all the information in the files without it just being a massive dump.
Some of the reasons are:
The components were once marked permanent, or given a null guid. These are settings that propagate to the system. If you install with these set they stick to the the system and turning them off in the project won't change that.
Stein's answer - marked shared at install time. There's never a reaon to do this unless you know that a non-MSI install might install the same files to the same location (and set SharedDllRefCount) after your install.
There's also another shared bit, msidbComponentAttributesShared, and that tells Windows it's shared among multiple MSIs even if it was not in some of those installs. Very unlikely unless you are patching.
Running something like this VBScript to enumerate every component on the system will tell you if Windows thinks it's owned by an installed product:
Option Explicit
Public installer, fullmsg, comp, a, prod, fso, pname, ploc, pid, psorce
Set fso = CreateObject("Scripting.FileSystemObject")
Set a = fso.CreateTextFile("comps.txt", True)
' Connect to Windows Installer object
Set installer = CreateObject("WindowsInstaller.Installer")
a.writeline ("MSI Components")
on error resume next
For Each comp In installer.components
a.writeline (comp & " is used by the product:")
for each prod in Installer.ComponentClients (comp)
pid = installer.componentpath (prod, comp)
pname = installer.productinfo (prod, "InstalledProductName")
a.Writeline (" " & pname & " " & prod & "and is installed at " & pid)
Next
Next
Typically this relates to the flag Shared set to yes for the Components holding the dlls. This increments the SharedDLLRef Count in the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs. Combined With Installshield bugs this can leave the file on uninstall. The solution is to set the component holding the file to shared = no and delete the entries in SharedDLLs then try the uninstall again.
This sharedDLLs ref Count is a compatibility feature With non-msi installers and shouldn't be used in my opinion short of for files going to system32. MSI Reference Counts using the Component guids.
UPDATE: Enabling SharedDllRefCount sets the legacy ref-count here:
64-bit: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs
32-bit: HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\SharedDLLs
Cleanup:
Cleaning Up Your Shared DLLs Registry References for MSIs (untested by me).
And some further MSDN suggestions for stranded components.
Comprehensive explanation of reference counting errors.
Related
I have created bat file for automatic build. It's create installer of my product. But problem is that before run automatic build script I have to change product code manually from install shield. So, is there any way to change product code automatically ? because everything is automatic except product code.
As Phil says you can do this via the COM automation interface for Installshield, but there are also other ways as explained here: Installshield Build Automation.
Essentially:
The link above shows a small sample of how to use the standalone build executable ISCmdBld.exe - which you might already be using.
Something like: "[PATHHERE]ISCmdBld.exe" -p "MyInstaller.ism" -r SingleImage -y "1.0.0.13" -z ProductCode=%guid%.
Do check the above link out - I have never used ISCmdBld.exe opting for COM automation instead.
The linked answer also explains how to use msbuild, read Urman's answer.
Finally you can use the COM automation interface and a VBScript (or Javascript?), and I have added a small sample below for how this can work.
I don't have Installshield 2013 available, but here is a very rough sketch of how you can automate the latest version 2016 via COM automation using a VBScript:
' On Error Resume Next
Set isproject = CreateObject("ISWiAuto23.ISWiProject")
isproject.OpenProject "C:\InstallShield 2016 Projects\TestProject.ism", False
Set isproductconfig = isproject.AddProductConfig("MyNewProduct_1.0.16")
isproductconfig.ProductName = "MyNewProduct_1.0.16"
isproductconfig.ProductVersion = "1.0.16"
isproductconfig.ProductCode = isproject.GenerateGUID
' lots of properties to set, the above should normally suffice I think...
Set isrelease = isproductconfig.AddRelease("MyNewRelease_1.0.16")
isrelease.Compressed = True
isrelease.SetupEXE = True
' lots of properties to set...
' Save and build project
isproject.SaveProject ' For some reason the project won't save properly after it is built
isrelease.Build
isproject.SaveProject
' Report error status
WScript.Echo "Number of Build Errors: " & CStr(isrelease.BuildErrorCount)
WScript.Echo "Number of Build Warnings: " & CStr(isrelease.BuildWarningCount)
isproject.CloseProject
This script wasn't tested that thoroughly, and weirdly, the new product configuration and release are not saved unless you save before triggering the build. It might be something simple I have mixed up - or it might be a bug in the tool (it wouldn't be the first one).
Take it for what it is, let's hope it gets you going to work out the wilburys on your own (bugs). I think it might run if you change ISWiAuto23.ISWiProject to IswiAuto20.ISWiProject to match the Installshield 2013 COM server version.
Crucially, you must run the VBScript from a 32-bit CScript.exe / WScript.exe (don't ask me why). Just put a shortcut to C:\Windows\SysWOW64\cscript.exe on your desktop for testing, and drag and drop your script onto it, or better yet, open a command prompt and go to C:\Windows\SysWOW64 (believe it or not this is the 32-bit folder - and the System32 folder is 64 bit (!) - only in Windows!) and then type cscript.exe [FullPathToVBScript]. Obviously remember to close your ISM file in the Installshield GUI before running the script.
I like the fact that you can save the new release and product config inside the *.ism file so you have a record of compiled releases. I am not sure what ISCmdBld.exe does.
I think you are supposed to use the InstallShield automation for this kind of thing, such as the ISWiProductConfig object that exposes the ProductCode of the MSI you're building.
I am working on an installer with WiX which takes a "name" input from the user using a textbox in a dialog. This name will be used to name the product that i am installing.
But, i am not able to set the product name dynamically during install. Even if i use a custom action, the registry entry is getting created with the static name that i have provided earlier. This is ultimately leading to inconsistency.
Can anyone please help me regarding this?
This cannot be done in a custom action. It's true that you can set the ProductName property in a custom action (such as a type 51) early in the install and that will indeed change the name in the UI, but it will NOT change the name of the installed product - it will remain the same as the original value. For example, enumerating installed products will return the original name.
So the only good way to do this is to modify the ProductName in the MSI file before you launch it. You would have a launching program that modifies the MSI file and then installs it. The MSI file is a database that can be modified in the Property table to change the value of ProductName. This example will give you the general idea:
How do I add/update a property inside an MSI from the command-line?
but basically you open the open the database (MsiOpenDatabase or equivalent) then MsiOpenView with a SQL such as:
"UPDATE Property SET Property.Value = 'Your variable' WHERE Property.Property = 'CurrentProductName' "
then MsiViewExecute and close handles etc. Details depend on your preferred coding language environment.
This is not an ideal solution because if your MSI file is digitally signed you have tampered with it and it is no longer correct.
Another way is to generate a transform file, based on altering a copy of the MSI file. If you make a copy of the MSI file, and then do the alteration of ProductName as above you can then do an MsiDatabaseGenerateTransform() call which will generate a transform file, a .mst file, the difference between the two MSI files. You then install the original unaltered MSI file with a command line that includes TRANSFORMS=[the .mst file] which will update the ProductName and start the install.
None of this is very easy because Windows Installer products are not designed to have dynamic product names. Maybe historically and before Windows Installer setups this was more practical, but not in MSI setups.
I have a wix installer with five features. My current version is 0.0.0.125. I am installing this in one machine with first three features. Later i wish to install the remaining two features and so deselected first three and selected the remaining two features.
So this time the first three already installed should not be deleted, and the remaining two features should be installed. But when i install the same build second time, the three features are automatically removed from the destination location and the selected two features only installed.
I used RemoveFile child attribute to each Component to overwrite and when i manually copied the file and pasted into the destination directory, next time when i install the same version installer, it is not overwriting and deselected(previously installed features) features also deleted. So i have restricted this by adding 1 in InstallExecuteSequence.
i)I need to overwrite all the files
ii) Each installation of the same installer should not delete the previously installed files
Thanks
I can't tell exactly what you mean by features and installing the same setup twice, but:
You cannot install the same MSI setup twice. It's already installed (the ProductCode) so it will go into maintenance/repair mode. This may do a repair/reinstall or, if you've authored it for feature maintenance, then Windows will again notice that the product is already installed but offer the standard feature dialog which lets you add features from the setup, and this latter mode is exactly what you get if you go to Programs&Features and choose change. In other words a true feature maintenance setup offers the feature selection dialog primarily from Programs&Features, and in your scenario with adding two features you'd simply use Change from Programs&Features and not attempt to reinstall the same setup.
Your post refers to Components and RemoveFile, and you should definitely not need to do any of this. If you're not using true Windows Installer features and have built a Component-based setup where Component installation is based on conditions then that would explain what you are seeing. The property values used for your conditions are not preserved so when you attempt to install the same setup again it goes into maintenance reinstall mode for the currently installed product, the property values are empty, the conditions are false, so those components are removed.
Having said all that, you haven't posted your WiX, and the fact that you're attempting to install the same setup twice implies you may not be familiar with maintenance, features and components. In summary, it seems that you should be using the WixUI_FeatureTree dialog set, grouping your components into features to achieve what you're looking for.
If your aim is to replace files that need updating then you should look at the WiX MajorUpgrade element. If you set MigrateFeatures to yes then the upgrade will result in the same features still be installed after the upgrade. Schedule afterInstallExecute is probably what you want. Increment file versions of files you want updating, use a new ProductCode, increment the ProductVersion in the first three fields and use the same UpgradeCode. Alternatively you could look at creating a patch, an msp file.
Usually you would set Permanent="yes" for files that you want to keep on a computer after un-installation and "no" if want to remove or overwrite them.
For example:
<util:XmlFile Id="fileId"
Action="setValue"
Permanent="yes"
File='[INSTALLFOLDER]pathtofile\yourApp.exe'
ElementPath=""
Value=""
Sequence="1"/>
Hope this helps!
I have a .msi installer (via wix) for an application I'm working on but the application's version number doesn't fit the X.Y.Z version numbers required my MSI's registry Version so the version number is "mangled" into something that does fit and still increases with every release.
I'm okay with this.
msiexec, as part of it's final cleanup, converts this X.Y.Z integer-encoded version number into a string and dumps it into the DisplayVersion registry entry. What I'd like to do is overwrite that string with my own that contains the actual version number of my application.
This certainly seems possible. For example...
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\19BF4688EE4961F41A44D0282A2340D9\InstallProperties
DisplayName = (REG_SZ) "Configuration Manager Client"
LocalPackage = (REG_SZ) "C:\Windows\Installer\41202.msi"
DisplayVersion = (REG_SZ) "5.00.7958.1000"
Version = (REG_DWORD) 0x05001f16
The Version is the encoded value of "5.00.7958", so where did the rest of the DisplayVersion string come from?
How, using only wix/msi supported options, do I overwrite DisplayVersion in the registry with my own custom string?
Might be a larger change than what you're looking to make, but...
if you set ARPSYSTEMCOMPONENT=1 in your MSI it won't register an ARP entry for your product. Then you can create your own ARP entry for your product by populating the HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\[ProductCode] keys in the Registry table of your MSI.
I eventually accomplished this by having the MSI launch a custom installer binary near the end of the installation procedure. That program forks a background copy of itself and exits so that the install can finish.
The background task sleeps for a while to let the installation complete and then directly alters the registry to set DisplayVersion to the desired string.
There's a race condition here but it hasn't been a problem and updating the string isn't essential.
So, I have a WIX project which is to install either fresh installations or over previous installations of a product. This product, if it was already installed, has several files inside of 3 different folders which need to be preserved. This project also needs to copy the contents of those 3 different folders into another set of folders (same content in two different locations). In order to accomplish this I have set up my project to first attempt to write into the original folders if the files don't already exist, then copy the contents of those folders. On an upgrade where those files already exist this works fine. On a fresh install the second set of folders do not get created, but all the files do.
My assumption, and I may be incorrect, is that the msi is attempting to copy the folders over before they have even been created. This would cause folders to not exist in the area they were supposed to be copied to as there would be nothing to copy from. Is there a way I can ensure the files have been generated before trying to copy them? Is there a better way of going about this that I'm not seeing?
EDIT:
I'm going to try to clear this up a little. What I'm trying to do is the following (pseudo):
1) See if an option file (hi.opt) exists in c:\options, if not create it.
2) Copy that file to c:\options\opt2015.
I'm doing this 3 times for 3 different folders. I am creating the initial files with Wix in the c:\options folder using the NeverOverwrite parameter. This part works great; the files are created without issue and none are overwritten if they already exist. Where the problem lies is step two where I'm using the CopyFile Wix command. This will only copy some of the files from the c:\options folder to the c:\options\opt2015 folder. Depending on the initial setup of the system (if the files at c:\options exist or not) some files will copy over and others won't. It's not random, the results are repeatable every time, but there seems to be no reason why some files copy and others don't depending on the initial setup of the system.
I hope this makes sense and is a little more clear, though I think it makes things worse! It is strange behavior because to me it looks like everything should just work, but it doesn't (isn't that every bug though).
Edit2:
After more work and creating a vb script which runs perfectly outside of WIX my team and I have determined that the files just are not being seen by WIX during the installation even though they do exist. We haven't found any permissions issues and the installation is running as admin on an admin account. Doing the copy via a VBS or through the Wix CopyFile command results in, well the same results; files that already exist on the system are not being copied. Any more ideas? Should we find a solution I'll be sure to post it because this is just getting weird.
I believe your installer design should work as long as you're attempting to copy the files after the InstallFiles action runs. You should be copying the files from the first set of folders to the second set of folders by doing one of the following:
Running a deferred custom action that executes after InstallFiles
Using the MoveFiles action
This is too long for a comment, but may not be an answer either....
There isn't really such a thing as "over previous installations of a product", especially if you end up with multiple instances in Programs/Features, and files that may or may not have the same component ids replacing each other - that's going to be a mess. If you need to upgrade the installed product, use a major upgrade, that seems to be where you're going with this. If you are already writing custom actions to do some of this "first attempt to write into the original folders" then I've no idea what's going on or where you doing this in the install. In general, if you need those files in the new install then add them to the new major upgrade MSI. If you need to copy the older existing files from the older product, then do a major upgrade with afterInstallExecute and write custom action code to copy them before the InstallFiles action. Or the CopyFile WiX element could do it, see the part about the element under a component with no fileid.
http://wixtoolset.org/documentation/manual/v3/xsd/wix/copyfile.html
Well, as sometimes happens, the error was entirely elsewhere. It turns out that an uninstaller for another program which was in the chain of programs which are installed at the same time was destroying the folder. Unfortunately this is what happens when a product isn't touched for 10 years. Thank you for your contributions, they were very helpful. Even though I was going down the wrong path the whole time I still made use of them in my tests and am more adamant about checking the installation order.