Wix set program run as admistrator - wix

I have already set the program run as the windows startup, however the program can only work when it is run as administrator in windows 10, can anybody tell me what I should add in the code to set that? Here is my Wix code:
In product modules there is
<ComponentRef Id="RegistryEntries"/>
and then
<Fragment>
<DirectoryRef Id="ProgramFilesFolder">
<Component Id="RegistryEntries" Guid="14fe9526-0da4-4761-ad27-8a77f145c6b5">
<RegistryKey Root="HKCU"
Key="Software\Microsoft\Windows\CurrentVersion\Run"
Action="createAndRemoveOnUninstall">
<RegistryValue Type="string" Name="March Networks Video Assistant" Value="[INSTALLFOLDER]March Networks Video Assistant.exe" KeyPath="yes"/>
</RegistryKey>
</Component>
</DirectoryRef>
</Fragment>
Thank you so much to everybody.

The problem is you are putting this registry key in the HKCU which will run things in the current user's context at startup.
If you want it to be run as administrator on startup it needs to go into HKLM.
Try the following:
<Fragment>
<DirectoryRef Id="ProgramFilesFolder">
<Component Id="RegistryEntries" Guid="14fe9526-0da4-4761-ad27-8a77f145c6b5">
<RegistryKey Root="HKLM"
Key="Software\Microsoft\Windows\CurrentVersion\Run"
Action="createAndRemoveOnUninstall">
<RegistryValue Type="string" Name="March Networks Video Assistant" Value=""[INSTALLFOLDER]March Networks Video Assistant.exe"" KeyPath="yes"/>
</RegistryKey>
</Component>
</DirectoryRef>
</Fragment>
So notice I changed HKCU to HKLM (this might cause ICE warnings during compilation but you can safely ignore them). If you are using a per user install, I don't know if this will be able to write the registry key though unless the install is run as administrator... Also I put " around your RegistryValue's value since it's always nice to wrap full paths in quotes because of spaces.
Another nice thing you can do is update the RegistryValue's value using the install path of the component which can be referenced using the following syntax:
[#IDOfFile]
So if your component defining the "March Networks Video Assistant.exe" <File> uses Id="MarchNetworksVideoAssistant.exe" you can update your RegistryValue's value to
value=""[#MarchNetworksVideoAssistant.exe]""
You can get a good explanation of this syntax here
If a substring of the form [#filekey] is found, it is replaced by the full path of the file, with the value filekey used as a key into the File table. The value of [#filekey] remains blank and is not replaced by a path until the installer runs the CostInitialize action, FileCost action, and CostFinalize action. The value of [#filekey] depends upon the installation state of the component to which the file belongs. If the component is run from the source, the value is the path to the source location of the file. If the component is run locally, the value is the path to the target location of the file after installation. If the component has an action state of absent, the installed state of the component is used to determine the [#filekey] value. If the installed state of the component is also absent or null, [#filekey] resolves to an empty string, otherwise it resolves to the value based upon the component's installed state. For more information about checking the installation state of components, see Checking the Installation of Features, Components, Files.

Related

WIX — Add files to both GAC and INSTALLFOLDER without changing the name

Despite the different Ids and GUIDs the following code refused to compile because the following components have the same name. Setting the Name attribute does the trick, but I don't want libraries to have different names in GAC and install folder.
So far I have circumvented the issue by creating a CustomAction that renames one of the components on install, but this clearly isn't optimal. Is there an out of the box solution?
<ComponentGroup Id="HistoryGroup" Directory="INSTALLFOLDER">
<Component Id="History" Guid="*">
<File Source="$(var.ProjectName.TargetPath)" KeyPath="yes"/>
</Component>
<Component Id="HistoryGAC" Guid="*">
<File Source="$(var.ProjectName.TargetPath)" KeyPath="yes" Assembly=".net"/>
</Component>
</ComponentGroup>
Give both file elements explicit unique Id attributes. For the one going to the GAC install it to another dummy folder that already exists. (Don't worry it won't get installed there, it'll go to the GAC.)

WIX does not remove shortcuts in the INSTALLDIR if not default

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.

32bit wix installer registrys the key to the regular and wow directories but it only deletes the regular one in wix

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.

Wix - How to get user input from a previously installed msi?

I'm trying to do an installer using wix 3.8. I can use custom properties to store my own input, but I'd like to use values that where inputs on a previously installed msi.
Is there a way to accomplish such thing?.
To get you in the right direction add this (of course adapt it to your needs first) in your fist MSI:
<DirectoryRef Id="INSTALLDIR">
<Component Id="RegistryEntries" Guid="{0AC76129-F8E2-47D3-B9FD-09B1E10A8541}">
<RegistryKey Root="HKLM" Key="Software\Company123\App123" Action="create">
<RegistryValue Type="integer" Name="SomeIntegerValue" Value="1" KeyPath="yes"/>
<RegistryValue Type="string" Name="UserInput" Value="[USERINPUT]" />
</RegistryKey>
</Component>
</DirectoryRef>
Don't forget reference the component in your <Feature> <ComponentRef Id="RegistryEntries" />
When you install assign a value to the property [USERINPUT] e.g. msiexec /i your.msi /qb+ USERINPUT="the value to be saved in registry"
Then in the second MSI add something like this:
<Property Id="READREGISTRY">
<RegistrySearch Id="USERINPUT_Value" Root="HKLM" Key="Software\Company123\App123" Name="UserInput" Type="raw" />
</Property>
The value/string you entered during installation USERINPUT= will be stored in your second MSI in the property READREGISTRY
Here a piece of log in my second msi:
PROPERTY CHANGE: Adding READREGISTRY property. Its value is 'testing registry wef wef wef w'.
Based on your installation where it might be Per User or Per Machine you may adjust the Root to HKCU for PerUser installs or leave it to HKLM for PerMachine.
For more information please refer to Wix documentation, hints: "How To: Write a Registry Entry During Installation" and "How To: Read a Registry Entry During Installation".
Generally, no. There is no requirement for a Windows Installer package to record the input it takes from the user. Some do record some information in the registry and you might choose to rely on finding it there.
As an alternative, you might find that the other installer can be run without a UI and can be sufficiently controlled with properties passed into it. If so, you can write your own UI (one way would be a custom WiX Bootrapper Application [example]) to gather the inputs before running the installer.
Create a custom action within the MSI which gets installed first, then either write the values/user entries that you want into a file or registry. Within your final MSI read the values from registry/file and use it.
Here is an example of how you can read a value from the user and update the your app.config, this is not an apple to apple scenario, but this will guide you through it.
http://bensnose.blogspot.com/2013/03/more-custom-actions-with-wix.html
Disclaimer: I havent tried out what is mentioned in this blog post, but I have done things very similar and found that it has good explanation, thats why I posted the link to it.

Remove registry keys under HKCU on a per machine installation

I build a perMachine installer using WiX 3.6 to install a software I had not developed. Unfortunately the software creates some registry keys under HKCU during execution.
On uninstall, the self created keys should also be removed. It seems not so easy to remove these keys. I am "fighting" with ICE57 and/or ICE38. Both complaining the mix between perUser and perMachine data.
Hopefully you can point me in the right direction on fixing this issue.
To overcome ICEs you should move Per-User registry to separate components and use some registry entry as keyPath for that component, i.e.:
<Component Id='PerUserRegistry' Guid='*'>
<RegistryValue Id="PerUserRegistry_KeyPAth" KeyPath="yes" Root="HKCU" Key="Software\[Manufacturer]\[ProductName]\[ProductCode]\PerUserRegistry" Name="[PackageCode]" Value="[ProductVersion]" Type="string" />
<!--Other Per-user registry goes here-->
</Component>
I completely agree with Christopher: It is common practice to leave per-user data on uninstall, but if removal is necessary, then Active Setup is the only real option.
First I propose you to remove them on Install or Re-Install instead of uninstall, you just need add RemoveRegirty entry and Active Setup, i.e. with this WiX code:
<Component Id='ActiveSetup' Guid='*'>
<RegistryValue Id="ActiveSetup00" Root="HKLM" KeyPath="yes" Key="SOFTWARE\SOFTWARE\Microsoft\Active Setup\Installed Components\[PackageCode]\" Name="StubPath" Value="msiexec /fup [ProductCode] /qb-!" Type="string" />
<RegistryValue Id="ActiveSetup01" Root="HKLM" Key="SOFTWARE\SOFTWARE\Microsoft\Active Setup\Installed Components\[PackageCode]\" Value="[ProductName] [ProductVerion] Configuration" Type="string" />
</Component>
<Component Id='PerUserRegistryCleanup' Guid='*'>
<RegistryValue Id="PerUserRegistry_KeyPath" Root="HKCU" KeyPath="yes" Key="SOFTWARE\SOFTWARE\Microsoft\Active Setup\Installed Components\[PackageCode]\" Name="StubPath" Value="msiexec /fup [ProductCode] /qb-!" Type="string" />
<RemoveRegistryKey Id='PerUserRegCleanup' Root='HKCU' Action='removeOnInstall' Key='Key\To\Be\Removed'/>
</Component>
Note: [PackageCode] use in ActiveSetup is very recommended, so with each new version (build) of MSI package you add separate entry (also see my final note). I used per-user active setup registry as key-path on purpose, so you don't run it for current user twice.
As for removing them after uninstall,
Now, hopefully you need to remove entire key, and not just some values. In either case, I would create custom action to add Registry entry for Active Setup during uninstall (or if there are many such keys/values, create and deploy .CMD file with those and launch it on uninstall, before RemoveFiles action, to add all of them to registry).
Note: that I would strongly recommend adding deleting this registry during install, or you might end up removing per-user values when software is yet installed.
So here's WiX code for all of this:
<CustomAction Id="CA_UninstallRegistryCleanUp" Directory="SystemFolder" ExeCommand="REG.exe ADD "HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\MySoftName_CleanUp" /v StubPath /d "reg add ^"HKCU\Key\To\Be\Removed^" /va /f" /f" Return="ignore" />
<InstallExecuteSequence>
<Custom Action='CA_UninstallRegistryCleanUp' After='RemoveRegistryValues'>REMOVE~="ALL"</Custom>
</InstallExecuteSequence>
<Component Id='RegCleanup_Remover' Guid='*'>
<RegistryValue Id="PerUserRegistry_KeyPAth" Root="HKLM" KeyPath="yes" Key="SOFTWARE\[Manufacturer]\[ProductName]\[ProductCode]\" Name="DummyKey" Value="[ProductVersion]" Type="string" />
<RemoveRegistryKey Id='RegCleanup_Remover' Root='HKLM' Action='removeOnInstall' Key='SOFTWARE\Microsoft\Active Setup\Installed Components\MySoftName_CleanUp'/>
</Component>
Final notes:
There just two small issues with all this Active Setup stuff: be careful on Windows Terminal Servers; and once active setup was run for one user for current .MSI, it will not run again if you decide to reinstall same package, unless you change its PackageConde or raise version under ActiveSetup registry key. These are topics for another day, let me know if need them clarified.
And don't forget to add all of above Components to some Feature.
The Windows Installer considers this user data and best practice is to not remove it. Either way, it's very difficult to try to remove it anyways since other user profiles are out of scope / context. It's theoretically possible to write a custom action to enumerate profiles and load registry hives but on some versions of Windows ( Vista ) that won't work due to restricted permissions granted to the windows installer service.
If you really, really must be able to remove custom action data on uninstall then take a look at:
Active Setup Explained
You are going to need to leave behind an program (exe for example ) by marking a component as permanent. Then you'll need a custom action to write a registry value during the uninstall (because Windows Installer doesn't support this).
The concept is during the install you lay down an EXE and during the uninstall you leave you. You then write to the ActiveSetup registry key telling it to run your EXE once for each subsequent user to logon to the machine. The EXE then deletes your registry values. Reboot (politely) if needed to unload the extensions from explorer.
But honestly, a better designed application wouldn't need all of this.