I have an application with a bootstrapper that installs multiple components below it. The code below uses ninject to have a loosely coupled database layer.
With regards to the bundle/bootstrapper, I would like to move the database layer out into a separate msi in order to support optional data layer choices on install (e.g.: radio buttons to install SQLite/SQLExpress/MySQL etc..).
I am struggling to figure out how to get the install directory working though, as the database components needs to install into the root/install directory of the main application. (rather than using the gac etc).
How can I do this? I have tried the steps mentioned here: How to use properties to set the installation path? but to no avail. I must have something wrong.. but given the code is spread over 5(ish) files, it seems a little large to load here!
Any pointers to get started trying to implement this, or should I go ahead and upload the code?
The method you refer to should work. Note however that the name of the property given in
<MsiProperty Name="INSTALLLOCATION"
should match the name used in wxs file of the corresponding MSI package. Typically if the MSI was created based on WixUI_InstallDir template the name would be APPLICATIONFOLDER and in the default template without the UI it is INSTALLFOLDER.
Related
I am creating a new version of an existing setup with WiX.
In the process, the version of an included third party product has been updated. It consists of several files (DLLs, Configs, exes), each of which is in its own component.
Do I need to change the GUIDs of all these components?
The new version of the third party product requires a newer VC redist package than the old version, so it is not backward compatible.
The names and destinations of the affected files are the same.
I have read
https://learn.microsoft.com/en-us/windows/win32/msi/changing-the-component-code?redirectedfrom=MSDN
Change my component GUID in wix?
but I am honestly even more confused now.
If it wasn't for the redist dependency change thing, I would have just put the new files in the places of the old ones and left the GUIDs the same.
But now?
The names and destinations of the affected files are the same.
Overall: This basically means that you should keep the same component GUIDs as before. The component GUID essentially identifies a target destination. If the target destination (the absolute path) changes you need a new component GUID.
File Name Change: Keep in mind that renaming a file changes the absolute path even if the path stays the same - hence you need a new component GUID for such file name changes.
Runtime: The incompatibility of the runtime should be irrelevant for the component GUID issue. What third party product is this? Perhaps it has its own installer? If it does it can potentially interfere with your installation in other ways (COM registration etc...).
Setup.exe Launcher: The standard procedure is to bundle runtimes in a setup.exe wrapping your MSI and all runtimes it requires. WiX offers the Burn framework to make such setup.exe launchers. Perhaps try my deployment info search grid for info on Burn. Also: Make yourself a single page PDF explaining your application's runtime requirements for corporate use and include it in your setup.exe so your setup is easy to deploy large scale.
The MSI File Itself: You can also add launch conditions to the MSI to identify that a required runtime is missing (so you can abort) - or you can use a custom action to inspect the system (I find this more flexible, but custom actions in general are complex. Use them read-only - for inspection only, and they are safer).
Links:
Will change in ComponentID for component in Windows Installer effect during upgrade scenerio.?
We have 2 installer sources in WiX to create installer for a single product with same Product Version, GUID and Package GUID also.
Those 2 installer projects will yield different outputs, one output being just a single MSI file (File1.msi) and other project output is a CD-ROM structure having different MSI file name (File2.msi).
So now issue arises when we installed the product using single MSI file, upon that if we invoke MSI from the other CD-ROM output, we end up getting below mentioned error.
I tried keeping same MSI filename for both kind of installer output, then this above error dialog was resolved but repair functionality isn't working.
If some files were deleted in the product's destination folder, it says source file not found error pointing to CD-ROM installer source folder.
Please help where I'm going wrong. I want to support Repair installation without this errors.
The dialog is expected. You can't change the name of the MSI except during major upgrades.
After that, if you rebuilt to create the different layouts, each MSI probably has a unique PackageCode and that makes them unique packages. That is most likely why repair isn't working. A verbose log file should tell all.
Updated: Compile your main MSI, then run administrative image on it and put the extracted files and MSI on the CD? Put the compressed
version on there as well - just in case they prefer that kind of
release (happens).
I am not sure what will happen when you run both setups this way, but
I think the MSI flagged as an administrative image extract might be
detected by the engine. I am not sure. Should work. Built-in approach for MSI, and you are not fighting wind-mills.
User Accounts: Are you creating any NT User Accounts? Did you set the FailIfExists attribute to yes? Please check here:
User Element (Util Extension). What is the setting for UpdateIfExists? (if any).
Other Issues: There might be other issues as well as Rob mentions. You can not use the same package code for both release types because a package code by definition identifies a unique file. All kinds of X-Files-like problems occur if you try to "hack" this. Not a fight you want to take on.
Administrative Installation: Why would you want to distribute different setups on CDs these days? Corporations that use your setup will run an administrative installation on your setup extracting all files - which is a much better concept. It is essentially a glorified file-extraction, and it is a built in Windows Installer concept intended to make a network installation point for software - among other things. It essentially extracts all files and translates the Media table to use external source files.
List of Links:
What is the purpose of administrative installation initiated using msiexec /a?
Extract MSI from EXE
I am in the process of migrating all my projects one by one from Installshield to Wix and I would like to find out the best way to deal with env specific files.
Our current process is:
Using Installshield we create a base MSI and a Transform file which would install the base MSI and a directory structure with files present in the current directory. Ofcourse in my source control, I have separate config files for different environments and my Deployment script picks up the right set of files and puts them in a staging location.
For example, Current dir looks like as follows:
sample.msi
sample.mst
test\apps\docs\global.config
test\files\docs\global.config
sample.msi gets installed and the above directory structure gets copied to the target location.
During Uninstall the directory structure gets removed as well.
I tried to recreate this behavior using CopyFile element but during uninstall the copied files stay and do not get removed. Is there another way to achieve this?
I understand the way we do our packaging might not be the best way to get around our requirements. If someone has a better way to do this, please let me know.
I am still very new to Wix and I haven't looked at any of the wix extensions so wouldn't know what else is out there.
As always, any help is greatly appreciated.
Do these files really have to be seperate from the msi?
Using wix you could put them all into the msi and install them based on certain conditions like settings properties or using a custom action. Doing it that way should make it rather easy to let the msi create the directories and copy the files, and also remove them when uninstalling.
Conditions would work like this:
<Component Id='MyComponent' Guid='PUT-GUID-HERE'>
<Condition><![CDATA[YOUR-PROPERTY = "SOME_STRING"]]></Condition>
<File Id='readme' Name='readme.txt' DiskId='1' Source='readme.txt' />
</Component>
A CustomAction in Wix can be a .net dll, the manual explains how this is done here:
Adding Custom Actions
IF you have the WIX Toolkit installed you just need to create a Custom Action Project.
Looking for a way out of the corner my company has painted itself into.
Windows Services are currently installed by manually copying files around and running various batch files to install / uninstall. Locations differ by site and depending on whether the installed code is for production or test usage. So my debug build might need to install into
C:\someFolder\Site1\Test
while the Release build of the same code would install into
C:\someFolder\Site1
Currently only 2 sites but probably expanding soon.
I'm trying to put together a WiX install project (VS2010, WiX 3.5) to handle the installation. I'm not able to change the install folder definition (much as I would like to!) and I'm running into problems trying to understand how I might approach the problem. Being a newbie to WiX doesn't help.
For the question about release/debug versions:
At the place in your code where you are defining your target directory, you can conditionally set it based on the build version. For example, Debug is an available variable that can be used like:
<!-- inside of somefolder/site target definition, conditionally append test dir -->
<?ifdef var.Debug ?>
<Directory Id="TestId" Name="test" />
<?endif?>
You can also add other build dependent variables in visual studio for each type of release. This would be a unique build for each target situation model. This could easily get confusing to users about which version they should use.
The other model - one build with flexible target locations:
For the different site directories: Depends on how those sites are created.
If they exist previous to your install, just use wix's directorysearch to set a property used to build the target directory.
If instead the target directory is decided at install time, and its based on user's decision, then you'll need to prompt for the name or type (site). This will be similar to the typical situation of asking for a custom install directory. You can modify one of the sample custom wix dialogs included in the wix source that do this and add that dialog to your project's next/back flow.
I'm using latest votive (Wix v3.5) and created a simple Wix VS 2010 setup project. I added my website reference and set the Harvest option as true.
Now since my INSTALLDIR points to a folder under IISROOT, I get this light.exe error:
[filepath]: error LGHT0231: The component
'cmp93982C4086FF8C75F07339DD7CEA8152' has a key file with path
'TARGETDIR\webdir...[filename].xml'. Since this path is not rooted
in one of the standard directories (like ProgramFilesFolder), this
component does not fit the criteria for having an automatically
generated guid. (This error may also occur if a path contains a
likely standard directory such as nesting a directory with name
"Common Files" under ProgramFilesFolder.)
While I understand the reason behind this error, I don't necessarily agree to its rational (maybe I don't understand the innate workings of Wix MSI generation).
How can I resolve this error?
To provide some context:
I'm trying to set this up in conjunction with Team Build. I can use the legacy format and run Heat/Harvest task against a folder to bypass this issue but do not want to go the legacy route.
I have not played enough with the new workflow based build definition, so not sure how I can incorporate this custom task.
I need to run harvest every time the Setup project is built because I do not want to keep track of hundreds of files manually.
The problem is because the component is rooted in TARGETDIR, which WiX cannot use for automatically generating a guid. You can add Directory/#ComponentGuidGenerationSeed to a directory above this component to avoid the problem. By adding this attribute, you must now take responsibility for ensuring the component doesn't get installed to two different directories across upgrades.
In Windows Installer, components need to have a guid that doesn't change between patches, minor upgrades, and major upgrades. As a convenience, WiX can generate a version 5 UUID for you using the component's directory hierarchy as the seed. But, TARGETDIR is ineligible for this.
I believe the reason is that TARGETDIR changes across installations (it's set to the drive that has the most free space). One of the component rules is "each component must be stored in a single folder". If TARGETDIR changed between major upgrades, then you could end up trying to install the same component to a second folder.