When our product upgrades on a Windows Server 2012 machine, the old shortcut is left behind in the Start menu. The executable is removed from the system, but the old shortcut remains which causes an error when a user clicks it since it is not longer on the system.
This does not happen on windows 2008 R2, and I do not think there is a problem with how our msi is built. I am asking the question here to see if others have experienced the same issue.
In case it may help, we are building the msi with WiX and here is the code snippet:
<DirectoryRef Id="The_ShortCut">
<Component Id="The_ShortCut" Guid="{our-guid}">
<Shortcut Id="TheShortCut.exe"
Name="Config Wizard"
Description="$(var.ProductNameLong)"
Target="[ShortCutFolder]OurCompany.Product.TheShortCut.exe"
WorkingDirectory="ShortCutFolder"
Icon="TheShortcutIcon.Ico">
<Icon Id="TheShortcutIcon.Ico" SourceFile="oursourcepath"/>
</Shortcut>
<RegistryValue Root="HKCU" Key="Software\OurCompany\OurProduct" Name="installed" Type="integer" Value="1" KeyPath="yes"/>
<RemoveFolder Id="Remove_Product" Directory="OurCompany" On="uninstall"/>
<RemoveFolder Id="Remove_Product_ShortCut" Directory="OurProduct_ShortCut" On="uninstall"/>
</Component>
</DirectoryRef>
I got this satisfactory answer from a coworker:
This doesn’t look like an issue with your package itself. The pinned item is just a reference to the *.lnk file at the location you had when you first pinned it. If you right-click the broken tile after upgrade and go to file location, it takes you the old shortcut folder (which no longer exists since the folder path has been changed).
It all seems like expected behavior. Judging from this thread, I’m not sure there’s a way to update the pinned item programmatically either.
Cheers!
Related
I've inherited project with MSI created in WiX and now I'm trying to solve some of the issues that unfortunately exist.
There's a remember property pattern which is used to found specific directory saved in registry entry:
<Property Id="AUTO_FOUND_DIR" Secure="yes" Admin="yes">
<RegistrySearch Id="regsrch_AUTO_FOUND_DIR"
Root="HKCU"
Key="$(var.RegPath)"
Name="$(var.SpecificKey)"
Type="raw"
/>
</Property>
The SpecificKey value is then saved in AUTO_FOUND_DIR property.
Then the black magic appears. A separate component is holding (among other stuff) a shortcut located in ProgramMenuFolder (non-advertised) to the main executable.
I've been told that usage of util:RemoveFolderEx is a workaround for an old issue where this shortcut was orphaned and hasn't been removed during uninstall:
<Feature>
<DirectoryRef Id="ProgramMenuDir">
<Component Id="cmp_ProgramMenuDir" Guid="{0E8BD13A-GUID-IS-HERE-6E5092ECA9EF}">
<CreateFolder />
<RemoveFolder Id='ProgramMenuDir' On='uninstall' />
<RegistryKey Id='reg_SpecificKeyID' Root='HKCU' Key='$(var.RegPath)' ForceCreateOnInstall="yes">
<RegistryValue Type='string' Name='$(var.SpecificKey)' Value='[ProgramMenuDir]'/>
</RegistryKey>
<!-- other content: shortcut to ProgramMenuFolder and other stuff -->
<util:RemoveFolderEx Id="rm_dirID" On="install" Property="AUTO_FOUND_DIR"/>
</Component>
</DirectoryRef>
</Feature>
The problem is: I don't need this workaround (and usage of AUTO_FOUND_DIR property as well. I've removed that code but during upgrade (major, Product and Package GUIDs set to "*", UpgradeCode has the same value as previous version) I can see in verbose log from MSI that this AUTO_FOUND_DIR exists, the RegistrySearch reads the key value with specific directory and as a result the util:RemoveFolderEx removes that directory and all components that are there located.
My question is: how can I detect why this old property is being used during upgrade and how to get rid of it?
Additional information: the install scope is PerMachine, ALLUSERS is set to 1. The MSI with upgraded version has this property removed.
Without a close look at your complete verbose log to see what's going on, remember that an upgrade does an uninstall of the older installed product. This means that a lot of the logic in the older installed product will happen during your upgrade. So you will definitely see the RegistrySearch running as the older product uninstalls, setting AUTO_FOUND_DIR, and you will see the RemoveFolder that runs during the uninstall.
So it's not clear if you actually have an issue if all you're seeing is the uninstall activity of that older product being uninstalled. That activity is embedded in the installed product.
Why WIX does not remove a shortcut in the INSTALLDIR if it is not the default install directory is used? My WIX code look like?
<DirectoryRef Id="INSTALLDIR">
<Component Guid="..." Id="shortcuts_INSTALLDIR">
<RegistryKey ForceDeleteOnUninstall="yes" Id="shortcuts_reg_INSTALLDIR" Key="Software\MyCompany\MyProduct" Root="HKCU">
<RegistryValue KeyPath="yes" Name="shortcut_INSTALLDIR" Type="string" Value=""/>
</RegistryKey>
<Shortcut Arguments="my args " Description="my description" Id="InstallDir_my_name" Name="my name" Target="[INSTALLDIR]mydir\my.exe" WorkingDirectory="INSTALLDIR"/>
</Component>
</DirectoryRef>
It look like that the uninstaller does not know the new value of INSTALLDIR. Any idea?
Windows Installer is a bit of an odd beast here. It doesn't record the operations it performs; instead it tries to record the information necessary to reverse them. In this case it appears you're falling into a gap in that implementation.
Windows Installer notes that it has installed component shortcuts_INSTALLDIR. When a file is installed to a specific directory, it records the directory's location. Then during maintenance it restores all the directories it recorded. But it does not record (and thus does not restore) the directory for just a shortcut. Typically shortcuts are installed to predefined paths under the ProgramMenuFolder. Since such locations are not affected by changes to INSTALLDIR, this is usually not a problem.
To solve this you have to ensure the alternate INSTALLDIR is restored during maintenance. You can convince Windows Installer to do so automatically by installing any file directly to INSTALLDIR (if the extra file is not a problem, this is my preferred option). Alternately you can do so manually through the remember property pattern, possibly leveraging ARPINSTALLLOCATION and its saved value in the Uninstall key.
my installer is a 32 bit program and when I install it to a 64 bit windows 7, it writes to the both 64 and wow directories in the registry. However, when I delete the program, the wow directory key is still left there so the DotNetInstaller still marks it as installed although it is not. Here is the registry key part:
<Component Id="ClientRegKey" Guid="{9239B7BA-71FA-4703-A597-355522505E7D}">
<RegistryKey Id="Registry_Client" Root="HKLM" Key="Software\Client\Client11"
Action="createAndRemoveOnUninstall" >
<RegistryValue KeyPath="yes" Name="Installed" Type="integer" Value="1" Win64="yes"/>
</RegistryKey>
</Component>
In your registry value element, why are you
mentioning win64=true?? Is that even a valid attribute, I don't see it in the documentation.
http://wixtoolset.org/documentation/manual/v3/xsd/wix/registryvalue.html
I think that attribute is causing the installer to create registry entries in the regular node. By default the x86 installer on windows 7 will only create the registry entries in the Wow node. Please remove that attribute and I think it would be fine.
From the documentation it also looks like the action attribute is deprecated, take a look at that as well.
I'm writing an installer pack for a product using Wix, the whole thing is in x86, but now i need to add a key to the x64 part of the registry. I looked around and found this stack answer which I thought would solve my problem. But I'm getting a ICE80 error (not a warning) which tells me that I basically need to change my Package Platform attribute to x64.
I would however rather avoid that because as I mentioned it's only one registry key that needs to be in x64.
So my question is: Is there another way to resolve the ICE80 error or do I need to build two msi packages, one for x86 and one for x64.
Here is some of my code to further illustrate what I'm trying to do:
<Component Id="Foo" Guid="{GUID}" Win64="yes">
<RegistryKey Root="HKLM" Key="Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\IniFiles">
<RegistryValue Type="integer" Name="Hello" Value="1"/>
</RegistryKey>
<Condition><![CDATA[VersionNT64]]></Condition>
</Component>
<Component Id="Bar" Guid="{GUID}">
<RegistryKey Root="HKLM" Key="Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\IniFiles">
<RegistryValue Type="integer" Name="Hello" Value="1"/>
</RegistryKey>
</Component>
Any help is appreciated!
Windows Installer doesn't support a 32-bit package writing to the 64-bit registry (or file system). A 64-bit package can write to both 32-bit and 64-bit portions.
Perhaps it didn't work then. I am using Wix v10 and in my x86 WIX project, and adding Win64="yes"initially generated ICE80 error. Once I suppressed that warning (in Visual Studio, "Tool Settings" -> "Suppress specific validation:" column), I no longer get that error. When I ran the x86 installer on Windows 2012 R2, those x64 reg keys were created.
Add Win64="yes" to the registry entry you want to put in the 64-bit in the registry..:) I have not included the condition in my own and it works perfectly with just the Win64 attribute.
Every update to new version WiX for some reason removed pinned start menu shortcut from taskbar. How can I fix this?
Shortcut was created using this command:
<DirectoryRef Id="ProgramMenuFolder">
<Component Id="GitExtensions.newstartmenu" Guid="*">
<Shortcut
Id="GitExtensions.newstartmenu"
Name="$(var.ProductName)"
Description="$(var.ProductName)"
Icon="gitextensions.ico"
Target="[INSTALLDIR]GitExtensions.exe"
WorkingDirectory="INSTALLDIR"/>
<RegistryValue
Root="HKCU" Key="$(var.InstalledRegKey)"
Name="GitExtensions.newstartmenu" Value="" Type="string"
KeyPath="yes"/>
</Component>
</DirectoryRef>
WiX code: https://github.com/gitextensions/gitextensions/blob/f9490e3e6e34cc2f6770fd9e1d6132cf5cfd0b0b/Setup/Product.wxs#L385-L399
Setup had been built in VS2010 + WiX 3.5.
It's actually doing a major upgrade and by scheduling RemoveExistingProducts early, the upgrade is removing the older version before installing the newer version. The shell removes the pin when the older shortcut is removed. You can try experimenting with a later scheduling of RemoveExistingProducts but note that there are costs associated with that.