I am quite new in creating setup project using .wxs file in .NET project. I knew that by default when you run MSI file it creates folder with this project and it's reference files (dll, exe, etc...) in C:\Program Files (x86). My question is, can I change this location in my .wxs file to another using XML.
ConfigurableDirectory: You can use the ConfigurableDirectory attribute of the Feature Element to set a configurable feature directory. See down the page in the screenshot section here: How to assign path value to Directory in WIX?.
Mock-up only:
Note: I am basing myself on the standard WiX Mondo dialog set. To hook up the Mondo dialogs, see this answer. Essentially, add reference to WixUIExtension.dll and insert the <UIRef Id="WixUI_Mondo" /> element. This will compile a default WiX dialog set into your MSI.
<Feature Id="MyFeature" Title="MyFeature" Level="1" ConfigurableDirectory="INSTALLFOLDER"></Feature>
<..>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLFOLDER" Name="InstallDirConfigurableTesting">
Remember Property: Note that you must persist the custom directory location yourself to the registry and read back for major upgrades or else your whole product gets "moved" during upgrades (I know, it is weird). This persisting does not happen auto-magically in any way that I know about. You can persist the property and read it back using the "Remember Pattern" as described by WiX creator and benevolency Rob Mensching here: The WiX toolset's "Remember Property" pattern.
Implementation Tip: Testing the read-back of the directory property for major upgrade scenarios can be a bit fiddly. If you create a test project in Visual Studio using Votive you can use the trick to just compile version 1 of your MSI (now suffix your MSI file in the build output folder with _Version1.0.0.msi or similar), and then kick up one of the first three digits of the version number property and build an upgrade version (suffix with _Version2.0.0.msi or similar). Then you install in sequence selecting a custom installation directory and check whether your second setup correctly detects the modified path. Just use a mockup or test harness project with a single component in it to get this working, or else you could drive yourself mad if you have to compile your whole setup. Then just inject your finished markup into the main project. Obvious, yes - just mentioning.
Some Further Links:
How to use ProgramFiles64Folder in ConfigurableDirectory
What is the meaning of WiX configurable directory?
Related
When uninstalling my application, I'd like to configure the Wix setup to NOT to remove few files that were added as part of the installation. It seems like the uninstaller removes all the files that were originally installed from the MSI file. How do I do that?
Here are my files which I wish to keep it forever
<Binary Id="RootCABinary" SourceFile="Assets\Certificates\RootCA.cer" />
<Binary Id="SubCABinary" SourceFile="Assets\Certificates\SubCA.cer" />
I have used WixIIsExtension.dll to install these certificates to the windows store.
Overwrite: Is it important that the file never gets overwritten? If so, add
"Never Overwrite" to your component. WiX attribute: NeverOverwrite="yes". Remember to test upgrade scenarios!
Permanent Component: As stated by Pavel, you can set a component permanent:
<Component Permanent="yes">
<File Source="License.rtf" />
</Component>
Blank GUID: Another way to do it is to set a blank component GUID. It essentially means "install and then leave alone". No repair or uninstall should be done (remember to add NeverOverwrite="yes" if the file should never be overwritten):
<Component Guid="" Feature="MainApplication">
<File Source="SubCA.cer" KeyPath="yes" />
</Component>
Read-Only Copy: I sometimes install files to a per-machine path (for example somewhere under program files) and then copy them to a per-user location (somewhere in the user-profile) on application launch, and then do operations on them that entail that the files should not be deleted. This is good in cases where you want to do something that change the files in question (they need to be writable). Then it is good to "untangle" them from deployment concerns (files will not be meddled with by installer operations at all - the installer has no knowledge of them). The original read-only copy installed to program files can be uninstalled though (no longer needed?).
Other approaches: You can also create such files using custom actions during installation (usually text files only), you can download the file in question from your web site on application launch (makes the file easy to manage and update / replace? Vulnerable to connection problems - firewalls, etc...) and the application can create the file using "internal defaults" in the main executable on launch. And there are no doubt further approaches that I can't recall.
Put your binaries in a separate WiX component and make it permanent. Have a look at this thread as well
In my Product, I've defined a custom action that looks like this:
<CustomAction Id="InstallScreensaver"
Directory="SystemFolder"
Return="asyncNoWait"
ExeCommand="rundll32.exe desk.cpl,InstallScreenSaver [#screensaver]"/>
following this blog post: https://ithoughthecamewithyou.com/post/wix-tricks-for-screen-savers
But when I link it (light) I get this error:
error LGHT0094 : Unresolved reference to symbol 'Directory:SystemFolder' in section 'Product:*'.
Why is that?
On Wix's documentation of predefined variables, I can SystemFolder:
SystemFolder - gets the well-known folder for CSIDL_SYSTEMX86 on 64-bit Windows and CSIDL_SYSTEM on 32-bit Windows.
and I also create a shortcut that uses that variable:
<Shortcut Id="Shrt_Install_Screensaver"
Name="Install Screensaver"
WorkingDirectory="SystemFolder" Icon="icon.ico"
Target="[SystemFolder]rundll32.exe"
Arguments="desk.cpl,InstallScreenSaver [#screensaver]"/>
Maybe try to add SystemFolder directly underneath TARGETDIR as a first test (compiles and runs for me with a rushed mock-up):
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="SystemFolder" />
<...>
</Directory>
I think this is enough for the msiexec.exe engine to "fill in the rest", even if you don't specify a real folder name since this is one of the System Folder Properties.
I am not sure whether to call your link problem a WiX bug or not. It should probably be handled auto-magically since the folder in question is a system folder. I would go with calling it a bug or a missing piece of auto-magic.
Is your screen saver 64-bit or 32-bit? For the record System32 contains 64-bit files and SysWOW64 contains 32-bit files, but I guess you already knew that. Only in Windows...
Some links for safekeeping:
How to reference SystemFolder in WiX Icon.SourceFile property?
"SystemFolder" in WIX and C#
Why does the TARGETDIR directory need a name?
In WiX files, what does Name="SourceDir" refer to?
I am using the Wix Toolset 3.8 Visual Studio add-in. I have created a WIX Setup Library which encapsulates some common components that will be consumed by various service deployment projects. This library includes references to several solution files which need to be packaged into each deployment.
These dependencies are used in my wix library fragments in a few different ways. For example:
<Binary Id="InstallationScript" SourceFile=".\Dependency1.vbs" />
<CustomAction Id="DependencyAction"
BinaryKey="InstallationScript"
VBScriptCall=""
Execute="deferred"
Return="check"
HideTarget="no"/>
<Component Id="DLL_Component" Guid="4745D9E2-0EBA-EE57-D8DB-677ADA9E9EC8">
<File Id="DLL1" Name="Dependency1.DLL" Source=".\Dependency1.dll" Vital="yes" KeyPath="yes" DiskId="1"/>
</Component>
The WIX Setup Library builds fine whether I add the files to the project as a link or copy them into the project directory, and whether I reference them in the project directory or use a relative path to their original location. The problem comes when I include the fragment in my WIX Setup Project for my service deployment.
<Custom Action="DependencyAction" Before="InstallFinalize">
NOT INSTALLED AND NOT UPGRADINGPRODUCTCODE
</Custom>
The Setup Project is not at the same relative depth in the folder structure, so a relative path does not point to the same place as it does when referenced from the WIX Library. When I reference the action or feature from the WIX library I get errors like The system cannot fine the file '.\Dependency1.dll' The XML is being read exactly as it is and referenced from the Setup Project location rather than from the Library Project location, so the relative directory is wrong. I can set the relative path in the WIX library to what it should be for the Setup Project that consumes it, or I can copy the solution files into the Setup Project directory as well, but of course, that completely defeats the purpose of using a common WIX library. There are other service deployment projects that need to consume this library.
So the question is, how do I reference solution files in a WIX library in a way that can be used by the Setup Project that consumes it, regardless of the directory that the Setup Project is in?
Create a binary .wixlib that contains the files referenced in your authoring. (That's -bf at the command line, BindFiles property in the .wixproj, "Bind files into the library file" checkbox in Votive.)
I'm using Visual Studio to build my wix file. So far I have one file Product.wxs and it's working for a simple install.
Now I want to add some custom dialogs. I think from the two articles below, I understand how to do it - after I get my environment set up:
http://blog.torresdal.net/2008/10/24/WiXAndDTFUsingACustomActionToListAvailableWebSitesOnIIS.aspx
and
http://www.merlinia.com/mdt/WiXTutorial2.msl
I downloaded the source, and I see 35 *.wxs file in this directory
wix35-sources.zip\src\ext\UIExtension\wixlib
This is where I'm starting to get lost.
Do I need to copy some (only the ones I want to change) or all these files to my Visual Studio Project. Until now, I have been running with none of these source files.
How does my Product.wxs know to use these files? Does it look at local directory first? Or do I have to rebuild some C# modules?
I included these lines in my Product.wxs, and it gave me the user interface at execution time:
<UIRef Id="WixUI_Mondo" />
<UIRef Id="WixUI_ErrorProgressText" />
Thanks,
Neal
Do I need to copy some (only the ones I want to change) or all these files to
my VisualStudio Project. Until now, I have been running with none of these source files.
Since you are already using WixUI_Mondo, I assume you want to customize that UI. Locate WixUI_Mondo.wxs in the wix sources, and copy that to your visual studio project. Rename the file to WixUI_MyCustomUI.wxs and change the UI Id attribute inside the file to Id="WixUI_MyCustomUI". You don't need to copy any other files yet; the dialogs referenced in the copied UI sequence are compiled into the wix tools as resources, so wix "knows" these dialogs by name.
In your product.wxs file, change the UI reference to <UIRef Id="WixUI_MyCustomUI" />. If you now rebuild your setup, the UI should still look exactly as WixUI_Mondo as we haven't customized anything yet.
If that worked, you'll probably want to customize or add a dialog. Again, you can start from an existing dialog by copying it from the wix sources. You'll also have to edit the WixUI_MyCustomUI.wxs file so that it uses your new dialog. Take a look at this other answer I wrote for an example.
How does my Product.wxs know to use
these files? Does it look at local
directory first? Or do I have to
rebuild some C# modules?
You do not have rebuild any C# modules. The only reason you downloaded the wix sources is because the existing UI sequences and dialogs are good examples to start from. In principle you could also ignore the wix sources and write these wxs files for the UI sequence and dialog definitions from scratch.
When you use the command line tools, you combine multiple wxs files by simply passing multiple file arguments and they will be compiled and linked together. If you use wix with visual studio, you just have to add the wxs file to the project. A non-trivial wix setup will typically be defined by many wxs files.
The content of a wxs file can container references to elements in other wxs files through elements such as UIRef, ComponentRef, ComponentGroupRef, DirectoryRef etcetera.
I wand to construct an MSI which, in its installation process, will deploy itself along with its contained Files/Components, to the TargetDir.
So MyApp.msi contains MyApp.exe and MyAppBootstrapperEmpty.exe (with no resources) in its File Table.
The user launches a MyAppBootstrapperPackaged.exe (containing MyApp.msi as a resource, obtained from the internet somewhere, or email or otherwise). MyAppBootStrapperPackaged.exe extracts MyApp.msi to a temp folder and executes it via msiexec.exe.
After the msiexec.exe process completes, I want MyApp.msi, MyBootstrapperEmpty.exe (AND MyApp.exe in %ProgramFiles%\MyApp folder so MyApp.exe can be assured access to MyApp.msi when it runs (for creating the below-mentioned packaged content).
MyAppBootstrapper*.exe could try and copy MyApp.msi to %ProgramFiles%\MyApp folder, but would need elevation to do so, and would not allow for its removal via Windows Installer uninstall process (from Add/Remove Programs or otherwise), which should be preserved.
Obviously (I think it's obvious - am I wrong?) I can't include the MSI as a file in my Media/CAB (chicken and egg scenario), so I believe it would have to be done via a Custom Action before the install process, adding the original MSI to the MSI DB's Media/CAB and the appropriate entry in the File table on the fly. Can this be done and if so how?
Think of a content distribution model where content files are only ever to be distributed together with the App. Content is produced by the end user via the App at run time, and packaged into a distributable EXE which includes both the App and the content.
MyApp's installer must remain an MSI, but may be executed by a Bootstrapper EXE. The installed MyApp.exe must have access to both MyApp.msi and EXE is to be "assembled" at runtime by the App from a base (empty) MyAppBootstrapper.exe, which is also installed by the MSI, and the content created by the end-user. The EXE's resource MSI must be the same as that used to install the App which is doing the runtime packaging.
WIX is not to be installed with MyApp.
There can be no network dependencies at run-/packaging- time (i.e. can't do the packaging via a Webservice - must be done locally).
I am familiar with (and using) Custom Actions (managed and unmanaged, via DTF and otherwise).
Add an uncompressed medium to your wxs like this:
<Media Id='2'/>
And then create a component with a File element like this:
<File Source='/path/to/myinstaller.msi' Compressed='no' DiskId='2' />
This will make the installer look for a file called "myinstaller.msi" on the installation medium, in the same folder as the msi that is being installed. The source path above should point to a dummy file, it is only there to appease wix.
Edit: The following sample test.wxs demonstrates that it works. It produces a test.msi file which installs itself to c:\program files\test. Note that you need to put a dummy test.msi file in the same folder as text.wxs to appease wix.
<?xml version='1.0' encoding='utf-8'?>
<Wix xmlns='http://schemas.microsoft.com/wix/2006/wi'>
<Product
Name='ProductName'
Id='*'
Language='1033'
Version='0.0.1'
Manufacturer='ManufacturerName' >
<Package
Keywords='Installer'
Description='Installer which installs itself'
Manufacturer='ManufactererName'
InstallerVersion='100'
Languages='1033'
Compressed='yes'
SummaryCodepage='1252'/>
<Media Id='1' Cabinet='test.cab' EmbedCab='yes'/>
<Media Id='2' />
<Directory Id='TARGETDIR' Name="SourceDir">
<Directory Id='ProgramFilesFolder'>
<Directory Id='TestFolder' Name='Test' >
<Component Id="InstallMyself">
<File Source="./test.msi" Compressed="no" DiskId="2" />
</Component>
</Directory>
</Directory>
</Directory>
<Feature
Id='Complete'
Display='expand'
Level='1'
Title='Copy msi file to program files folder'
Description='Test'>
<ComponentRef Id="InstallMyself" />
</Feature>
</Product>
</Wix>
Having one .MSI package launch another .MSI package from "within" itself is called a nested install, and it's bad juju (see Rule 20). Windows Installer has some global data that it uses to manage the current install, and it doesn't handle well multiple installs at the same time. For the same reason, if you start one install and then try to start another while the first is still in progress, you'll usually see a pop-up to the effect of "another install in progress, please wait until it's done".
You can have a program, usually called a bootstrapper (I think that's what you're referring to) which is itself not an install package, but which contains an install package (such as an .MSI or an .EXE) as a resource, possibly compressed. The action of the bootstrapper program is to extract/expand the resource to a file, commonly in a %TEMP% directory, then either launch the extracted .EXE or run MSIEXEC on the extracted .MSI. The bootstrapper can contain multiple resources and extract+install them one by one, if you need to install prerequisites before the main package. Or you can ship multiple packages as separate files, and have the bootstrapper execute/install them directly from the distribution media one by one, or copy them down to the target machine and run the series of install from there, or...
WiX itself does not get installed, no. It's a tool with which .MSI packages can be built. The WiX project has on its wishlist a generic bootstrapper program, but it hasn't been implemented yet. There are other bootstrappers available, e.g. this one.
You won't need a custom action -- in fact, since the bootstrapper isn't itself a Windows Installer installation package, "custom action" has no meaning to it. And, if you're familiar enough with CAs to know about managed/unmanaged/DTF, then you know enough to avoid custom actions whenever you can. (grin)
I think it's much easier for your bootstrapper to extract MSI file to some predefined location rather than to the temp folder. For example, to C:\Documents and Settings\All Users\Application Data\My Company\My Product Install Cache. After installation finishes bootstrapper would leave MSI file sitting there. If at some stage user decides to reinstall your product Windows Installer will be able to locate source MSI file.
Also, add path to this file to RemoveFile table so that it gets deleted on uninstall. You can use RemoveFile element in WiX for that.
So if I understand, then I think I would have the app create a transform (MST) that has the content files and apply that to the base MSI. I'm still not convinced that I understand though. :)
I'd configure the MSI cache path to a known location.
Then at runtime if you need to "edit" the MSI use VBScript or similar.
But still, I ask WHY!?!
I am also working on a way to deploy multiple MSI files. I have a bootstrapper.exe program that bundles the MSI files and runs them one at a time. This solves my problem for most cases.
The case it does not solve is GPO (Global Policy Object) distribution of the install. GPO requires a dot-msi file to run an install.
To do this here's what I did which almost solved the problem (but not quite). I put the dot-msi files in the file table of an installer and put my bootstrapper in the binary table and run it from a custom action inserted after InstallFinalize in the InstallExecuteSequence. Of course the bootstrapper won't be able to run other MSI's because the top level MSI holds the _MSIExecute mutex.
It was pretty easy to get a little further. I made the bootstrapper return control to the top level installer and continute. And then I added a WaitForSingleObject call to wait for the top level install to finish, and the bootstrapper can then continue to finish the install.
My problem is that the GPO installation happens at boot time and the top level install completes before the sub installers are done and GPO reboots the machine.
The toplevel install also returns a success status when the install may actually fail later on.
I'm still looking for a way to block the top level install from completing until after the bootstrapper completes.