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" />
Related
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'm finding that when I update the manifest for my bootstrapper to support Windows 10 compatability, the InstallUISequence of the MSI will correctly set VersionNT=1000, but the InstallExecuteSequence will set VersionNT=603.
How do I make the InstallExecuteSequence also set VersionNT=1000?
Here's my two cents....
I don't find the VersionNT property terribly useful. VersionNT64 is: VersionNT64 .... Not VersionNT64 to determine bitness.
This is a bit of a hack (they do this, we do that...) but desperate times call for desperate measures....
In all of the compatibility games MSFT is playing they only seem to be masking the Major and Minor but Build and revision. I've also worked out that on Win8 they mask it as 6.2 and on Win 10 they mask it as 6.3. So therefore I feel comfortable doing this:
<Property Id="WIN10FOUND">
<DirectorySearch Id="searchSystem" Path="[SystemFolder]" Depth="0">
<FileSearch Id="searchFile" Name="advapi32.dll" MinVersion="6.3.10000.0"/>
</DirectorySearch>
</Property>
What I tend to do ask myself is "WHY" do I need Windows (FOO)? I then look for some registry entry or DLL that indicates that particular feature, component, API is present and use that for my test.
Microsoft has adopted an evergreen approach of "you don't need to know what version it is, you'll always have the latest and it'll always be called Windows 10" and to me this reinforces the approach I prefer to take. I know that a day will come that they are wrong and I do need to know otherwise I'll install and my application will fail and my users will complain and not know what version they have. (Sigh...)
Microsoft official answer:
When you install an .msi installation package on Windows 10 or Windows Server 2016, the VersionNT value is 603.
Source
Since msiexec.exe does not have Windows 10 compatibility in its manifest, and VersionNT is a private property, there is no clean way I'm aware of to make the execute sequence see VersionNT=1000. I would recommend one of these approaches:
copy VersionNT to another property during the UI sequence (some public property like REALVERSIONNT; be sure to list it in SecureCustomProperties like any other property you want to pass to the execute sequence),
pass in the real value from your bootstrapper (ditto), or
possibly set a registry key in your bootstrapper if you need the same information during maintenance or uninstallation, then pull its value into the installation with a system search.
(I'm torn about the registry key option, as it can go stale if the OS is upgraded in the future. Note as well that all of these options are likely to be only as correct as the manifest on your bootstrap in a theoretical future version of Windows.)
I found that a very easy and robust way of detecting Windows 10 is by calling the built-in WMIC command and parsing the output from it:
wmic os get Name,Version,BuildNumber /VALUE
it'll return exactly the info you need to determine which OS you're on:
BuildNumber=14393
Version=10.0.14393
http://helpnet.flexerasoftware.com/installshield22helplib/helplibrary/whats_newIS2015.htm
On systems with Windows 10, the Windows Installer properties VersionNT
and VersionNT64 indicate 603, which was originally introduced as the
version number of Windows 8.1. Therefore, it is not possible to create
conditions in an .msi package that specifically target Windows 10.
Since Windows Installer 5.0 and Windows 7, DLL custom actions in .msi
packages are shimmed to block obtaining the operating system version;
the APIs GetVersion, GetVersionEx, and RtlGetVersion return a Windows
version of 6.0.6000, which was originally the version number of
Windows Vista. Therefore, it is also not possible to obtain the actual
version number of Windows from a DLL custom action or from an
InstallScript custom action (which is implemented as a DLL).
Because of the aforementioned behavior in Windows Installer, it is not
easily possible to detect what version of Windows on which an .msi
package is running
For installers that do not have a bootstrapper, I've found that creating an immediate custom action that calls GetVersionEx() and sets a property for the rest of the installer to use is also a good alternative.
I've sequenced my custom action to occur after AppSearch, and it was enough to condition components with it.
I have an InstallShield Basic MSI project which builds both 32-bit and 64-bit installers using Release Flags mechanism to build the different packages with the correct Template Summary, etc. One of my Components is an explorer.exe shell extension, so in order for this to work it needs to be registered in the 64-bit node in the registry when installed on windows 64-bit, NOT in the Wow6432Node. However, because this is a 32-bit Component to Windows Installer it will get registered as such and go down the Wow6432Node. I am told by InstallShield that this is native Windows Installer behavior and there is really no way around this other than Custom Actions (which I have already resorted to).
Do I have to resort to running regasm? This is what I currently do however I would rather not use Custom Actions for something like this. Also, it appears that other products have the same pattern: a 64-bit shell extension, however installed down program files (x86). I see TFS Power Tools and WinZip doing this for example. For these products, I do NOT see regasm.exe running so I assume they have some other mechanism for this.
Any ideas?
Did you try to set msidbComponentAttributesDisableRegistryReflection (Component table) attribute for that component?
Our company uses WIX for its installers, and we are now upgrading our application from 32-Bit to 64-Bit. For every new version, we always provide an upgrade path from the previous ones.
TODO list :
Binaries should now reside in the "C:\Program Files" folder instead of "C:\Program Files (x86)".
Registry entries should now reside in HKEY_LOCAL_MACHINE\SOFTWARE\%COMPANY% instead of HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\%COMPANY%
Log files, configuration files, and any custom files/registry entries needs to be moved over to their new 64-Bit locations.
Considered the special aspect of this upgrade, we are inquiring the community regarding its know-how.
Presumably you'll continue to have a 32bit MSI for 32bit customers. So I'd approach this was another MSI and reuse as many fragments as possible. Your directory table and ComponentIDs will be different and I'd also give it a different UpgradeCode GUID. In your MajorUpgrade I'd search for products having the 32bit UpgradeCode and the 62bit UpgradeCode and remove both when found.
I'd also make sure that you need to even do this. For example if I deploy a .NET app with no native dependencies ( say IIS, Winforms, WPF, Windows Service ) it'll JIT up 64bit no problem when possible even though I installed it using a 32bit MSI to 64bit locations. No harm no foul.
I have a .NET application that runs on both x86 and x64. I'd like to have a 32 bit WiX installer that will work on both platforms but I'd like it to install to /Program Files/ rather than /Program Files (x86)/ on 64 bit operating systems.
How do you go about doing this?
Update:
My idea was to assign the ProgramFilesFolder or ProgramFiles64Folder value to my own property, depending on whether it was a 64 bit environment or not, and then use that property value on the directory.
I have very little experience with WiX so if this idea is even possible I have no idea. If it is what would you test on to see if it is an x64 environment? Also how would you then assign a property value from ProgramFilesFolder or ProgramFiles64Folder depending on the earlier 64 bit environment test.
Any help is appreciated!
MSI doesn't support 32-bit packages installing to 64-bit directories.
While it's true that MSI's support here is weak, you might want to read the following article and comments then decide for yourself how you want to proceed.
http://blog.deploymentengineering.com/2008/01/even-developers-are-concerned-about.html
I just found this, I tried your exact idea and no dice. You can't actually access ProgramFiles64Folder unless you are running a 64-bit installer.
I've given up and am just installing my 64-bit component to ProgramFilesFolder. It's not that nice aesthetically but it works :)
I was able to install a x32 package with WiX into the \program files folder usig the idea from http://blog.deploymentengineering.com/2008/01/even-developers-are-concerned-about.html which is to:
1 - use ProgramFiles64Folder for the directory
2 - change the setup project's settings to add a compiler switch. Its on the 'Tool Settings' tab and you add '-arch x64' to the compiler settings.