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.
Related
Code snip:
<Component Id ="zyx" Guid="{4820d7d5-30a0-448c-a80e-83609c92f235}">
<File Id="DLLGAC" Assembly=".net" KeyPath="yes" Source="folder\pqr.xyz.dll"/>
</Component>
I'm trying to upgrade older version of assembly using above code but getting error
skipping installation of assembly component: {4820d7d5-30a0-448c-a80e-83609c92f235} since the assembly already exists
From my experience version of your library must be higher than installed library. And there's no option to copy with overwrite. So if library is yours - change version of library to higher.
If not:
In my case someone added to installer modified 3rd party with some higher version and it was impossible to replace it with official new version. Only way to solve it was custom action with simple File.Copy with overwrite.
How to create custom actions
<Component Id="zyx" Guid="{BB23E1A4-9270-41AA-9266-4D15506E1C63}" Win64="yes">
<File Id="DLLGAC" Source="folder\pqr.xyz.dlll" KeyPath="yes" Assembly=".net"/>
</Component>
After changing the code format it's working which is strange but it works :)
I have a registry value setter in my wix application as follows
<Component Id="EngageAssistanceAutostart" Guid="f9e92a81-506d-4fe9-836b-564420a98ea1" Win64="yes">
<RegistryValue Id="crimsonwatchdog" Root="HKLM" Action="write"
Key="Software\Microsoft\Windows\CurrentVersion\Run"
Name="Crimson watch dog"
Value="[INSTALLFOLDER]Crimson.Watchdog.exe"
Type="string" />
as you can see, to edit registry in windows 64 bit system, I have kept win64="yes"
and I also have to set patform="x64"
<Package InstallerVersion="200" Platform="x64" Compressed="yes" InstallScope="perMachine" InstallPrivileges="elevated" AdminImage="yes" />
if I didn't do this I wont be able to set reg. value in 64bit system.
if I do this, this installer wont work in 32bit system.
is there any solution which will allow me to set registry value in both 64 and 32 bit system?
You don't need to set platform to x64 to create registry in 64bit hive.
Component will decided where this registry will be created.
In your case, because it's only RUN key, you should create single component that is not set to x64.
What MSI will do whit such component.
On x86 machine, registry key will be created in standard location.
On x64 machine, registry key will be created under Wow6432Node but for Run this should be not a problem.
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 building an x86 compilation of a Wix project.
For some technical reasons, I need to copy some .dlls in system 32 folder. To do so, I wrote the following lines:
// In an external .wxs file
<?define System32Dir= "C:\Windows\System32" />
<Component Id="cmp32bits" Directory="System32Dir" Guid="*">
<Condition>NOT VersionNT64</Condition>
<File Id="file32bits" KeyPath="yes" Source="mypathtothefile" />
</Component>
<Component Id="cmp64bits" Directory="System32Dir" Guid="*">
<Condition>VersionNT64</Condition>
<File Id="file32bits" KeyPath="yes" Source="mypathtothefile" />
</Component>
But then it fails as System32Dir contains slashes, points...
Following this guide, if I use the SystemFolder for x86 systems and the System32Folder for x64 systems, when I install the product, for 64 bits machines the .dlls are installed in SysWOW64. I understand that, if I compile the Wix project in x86, the System32Folder will be translated the same for 64 bits systems.
That's the reason why I came to hand write the "C:\Windows\System32", but it's not working yet.
The question and important point is, how to copy anything in C:\Windows\System32 directory if I'm installing an x86 project into a 64 bits machine?
Thanks a lot.
EDIT: Added a CustomAction but could not make it work.
<CustomAction Id="CopyToSystem32" ExeCommand="[INSTALLFOLDER]copy.bat" Directory="INSTALLFOLDER" Execute="deferred" Return="asyncWait" />
<InstallExecuteSequence>
<Custom Action="CopyToSystem32" After="InstallFiles" >NOT Installed</Custom>
</InstallExecuteSequence>
Where the .bat file looks like this:
copy 64bits.txt C:\Windows\System32
But actually, I can't make the CustomAction work...
You can't officially install 64-bit components from a 32-bit package:
http://msdn.microsoft.com/en-us/library/aa367451(v=vs.85).aspx
and Windows will typically keep redirecting you to 32-bit folders.
I'd examine the reasons why you are being asked to install Dlls to the 64-bit system folder from a 32-bit install. If they are 64-bit Dlls then you potentially need a separate 64-bit install:
http://blogs.msdn.com/b/heaths/archive/2008/01/15/different-packages-are-required-for-different-processor-architectures.aspx
and if they are 32-bit Dlls then an app that requires them in the 64-bit system folder needs some re-architecting to get up to date with 64-bit systems.
I did the below things in my installer for this requirement.
Ship files to somewhere in installation location and later copy those files to “C:\Windows\System32” using DTF deferred custom action.
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!