I have to set Environment variable where this installer will be installed, but I am unable to do that.
I have tried the suggestions found in the following links without luck:
Can anyone give me a example of modifying windows environment system variables in WIX?
https://github.com/vibhorpg/wixsample/blob/main/Product_intel.wxs
So how can I set following environment on client system using WiX
<Environment Id="A_EXCELADDIN_LOG_PATH1" Name="A_EXCELADDIN_LOG_PATH" Value="%APPDATA%\A\logs" Permanent="no" Part="all" Action="set" System="no" />
That's generally how you do it. Only things that come to mind is first realize your specifying user profile so it'll only be for the person who installed the app and second Windows Installer doesn't update the environment variable if a reboot is pending. (Even if the pending reboot isn't from your MSI.)
Related
WiX installer uses regular dialogs for specifying the target path:
<UIRef Id="WixUI_Common" />
<UIRef Id="WixUI_InstallDir" />
<Property Id="WIXUI_INSTALLDIR" Value="INSTALLDIR" />
When the user just clicks through the installation wizard the default path is used. The user then runs the program (SomeExecutable.exe) and leaves it running. He then goes to list of programs and asks Windows to uninstall the program. The wizard properly displays a message saying that SomeExecutable.exe is running, so a restart would be needed. That's the expected behavior.
However if the user changes the target to something like c:\UserSpecificedFolder then installation works just fine but when an uninstall is attempted while SomeExecutable.exe is running then unistall finishes without any messages and files are not removed. The program continues running. That's not the expected behavior.
It looks like some extra step is needed to inform the installer that install path was changed and so it should treat the new path as install path when uninstall is being run.
Why would it not work?
What does the Windows Installer uninstall log say? I'm not completely convinced this is a problem even though it seems obvious. WiX only creates MSI databases. It doesn't do the uninstall, MSI does. MSI only prompts file in use / reboot interactions when it isn't able to do an operation. If there is no file lock it may be completely normal to not see it.
My follow up question would be is the file uninstalled at the end without rebooting?
in our bootstrapper WIX project, we have a lot of prerequisites, .MSI and .EXE files. Most of these will install just fine using the InstallCommand parameter in an ExePackage and the DisplayInternalUI parameter in the MsiPackage.
However, there is one program, namely Adobe iFilter, which is a .msi file, which has an installer that for some reason will NOT install with the parameter /quiet, but only /passive. The problem is, that trying to install the file using DisplayInternalUI="no" in WIX does not work, and there is no InstallCommand parameter for .msi files, so I can't silently install the program.
Is there any solution to this, as in, any way to give the .msi installer a "/passive" parameter through WIX? I didn't find anything like this in the documentation.
Thanks in advance.
On the topic of Adobe iFilter itself, interestingly enough, using /quiet DOES install the iFilter application, but DOES NOT set a link to Programs and Features, so you will not see it there or as an installed application in general. However, you can still find the installation files in its default install directory.
On installing something as quiet or passive in general, I have not found anything that allows this specifically, BUT normal Windows Installer Properties can be set using the
<MsiProperty Name="PropertyName" Value"PropertyValue"/>
tag within an MsiPackage.
See documentation here: http://wixtoolset.org/documentation/manual/v3/xsd/wix/msiproperty.html
This includes the "UILevel" property, which is found in every Windows Installer.
See documentation here:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa372096(v=vs.85).aspx
With this, you can set the installer to a reduced UI level, which I assume is the same as calling it with /passive.
I created a per-user installation MSI package.
According to tutorials, if installation does not write files outside of %USERPROFILE% and does not change the registry outside of HKCU, then such installation could be installed by a plain user without administrator rights.
But on my computers with turned on UAC (default level), the following message appears and the system asks for the administrator's login and password:
Do you want to allow the following program from an unknown publisher to make changes to this computer
Does my installation make some not-permitted changes? Or it is normal behavior of Windows 7 and a plain user cannot install per-user applications at all?
In addition to setting InstallScope="perUser" you must also set InstallPrivileges="limited" so you will have something like this:
<Package InstallerVersion="200" Compressed="yes" InstallScope="perUser" InstallPrivileges="limited"/>
The comment about unknown publisher is not administrator-related. It just means that the MSI file isn't signed.
You should post some of your WiX Package stuff in case you have just got InstallPrivileges set to Elevated or InstallScope as permachine. These can cause that elevation prompt.
Note that you don't get an elevation prompt, because Windows has detected that your setup might change restricted parts of the system, because it doesn't know yet! It's a setting in your WiX source. If the setup didn't get an elevation prompt and proceeded that's when you'd find out if you were violating security, and the setup would fail.
I want to install some files to a folder located at "C:\Users\Public\MyApp". Is there a pre-defined variable in WiX that resolves to "C:\Users\Public" in Windows 7 and equivalent location in other versions of Windows?
No. WiX defines only these variables in Setup projects:
sys.CURRENTDIR
sys.SOURCEFILEPATH
sys.SOURCEFILEDIR
sys.PLATFORM
And WiX variables are only used when the setup package is built.
You probably mean Windows Installer properties. They depend on the Windows Installer version are listed here. Note: when reading the required version of Windows Installer, the docs do you the disservice of listing the minimum version that could actually be installed on a particular operating system version. The minimum version to support a property would be the lowest of those.
The answer is still "no." In fact, there isn't even a CSIDL API to locate that folder. As of Windows Vista, there is a FOLDERID API, though Windows Installer doesn't use it.
The point is, that's not where installed files go! Please consider [CommonAppDataFolder].
This problem is solved as below:
<Directory Id="UserPublicMyAppFolder" Name="MineSched">
</Directory>
<SetDirectory Id="UserPublicMyAppFolder" Value="C:\Users\Public\MyApp" />
I've got an MSI built with WiX. It performs the following custom action:
<CustomAction Id='StartTray'
Directory='INSTALLDIR'
ExeCommand='[INSTALLDIR]\myapptray.exe'
Return='asyncNoWait'
Impersonate='no'
Execute='deferred' />
It is scheduled like so:
<Custom Action='StartTray' After='StartServices'>NOT Installed OR (TRAYWASRUNNING AND NOT REMOVE~="ALL")</Custom>
myapptray.exe happens to use impersonation to relaunch itself from its starting context of Local System (running from MSI context) as the user currently active on the desktop. This is not in my control and Impersonate='yes' does not work because the MSI may be invoked for an upgrade from the context of the system service, meaning Impersonate='yes' would still end up running the app as Local System.
I recently moved from including the VC9 CRT as a MSM in this MSI, to including it in a bootstrapper exe.
Doing this prevents the myapptray.exe custom action from running successfully. The impersonation fails in WTSQueryUserToken which returns ERROR_PRIVILEGE_NOT_HELD. This seems to imply that removing the MSM actually changed the user context in which the MSI runs, but that seems ridiculous. The only lines I removed from the wxs file are the <Merge> and <MergeRef> tags for the MSM, nothing else has changed.
What am I doing wrong?
I'd look more at what versions of the CRT your EXE was built against and if there are any policy rules saying what it can run against. Moving from an MSM to an EXE run before your MSI should generally be a good thing.
BTW, I did something really hacking like this once upon a time. We had to push an MSI out under the SYSTEM context using MSI. If a user was logged on we had to relaunch the application using the users desktop login session. I had a DCOM server installed configured to impersonate the interactive user to accomplish this. Really wierd, but there was a valid reason.
This was all before Restart Manager though.
I figured it out.
The CRT MSM was setting ALLUSERS=1 and the installer's behavior changed because it was not present in our base installer. The MSM's setting of ALLUSERS was inherited into the base installer as a result.
Setting ALLUSERS=1 in our wxs file fixed the problem!