I fell in love with CustomTable to build data-driven WiX installs. I had a custom action that I needed to execute on a dozen or so objects during an installation. Instead of having 12 <Custom Action=... entries in the InstallExecute sequence, I put all the appropriate stuff into a CustomTable and process via a loop inside a single CustomAction.
Now I want to leverage the functionality that WiX provides, such as XmlFile in conjunction with CustomTables. For example, I have a bunch of .config/xml files to process during the install; instead of having a million <XmlFile... elements in the Wix source I would like to add rows to the XmlFile table directly. Similar situation for configuring IIS where there are many WebApplication and WebVirtualDirs that I need to configure.
It looks like this can be done by inserting "temporary rows" into the appropriate table-- ie XmlFile or IIsWebVirtualDir. But I can't seem to find any examples of how to do this with DTF or otherwise.
Bob Arnson alluded to the fact that this is possible in an old post on joyofsetup that I came upon, unfortunately I can't find any other references to how to implement.
You can use the installer database functions from a custom action.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368250(v=VS.85).aspx
For details and some examples please see:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa372021(v=VS.85).aspx
Related
What is the standard way to handle web.config files during major upgrade.I'm aware how the unversioned files are handled during upgrade,the file will not be replaced if the file has been modified by the user.
Is there a way to deal with the scenario where in there are new entries added to config file bundled with the latest installer that needs to be installed,and also retain the existing entries modified by the user during major upgrade in Wix.
The simple solution that a lot of my customers have liked is to not put user data in the web.config. Instead we use the AppSettings#file and ConnectionStrings#ConfigSource elements to specify an override file and keep the user data there. What MSI doesn't know about it won't tamper with. Now you don't have to be an MSI component rules wizard.
https://msdn.microsoft.com/en-us/library/ms228154(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/system.configuration.sectioninformation.configsource(v=vs.100).aspx
I know the question is for Wix, but just wanted to point out how much time commercial tools can save in such scenarios.
For example, using Advanced Installer you can read and load into an MSI property any XML values and then use the XML Files updater to write dynamic content in the files, at install(upgrade) time. (check the videos at the end of each article for a quicker overview)
Disclaimer: I work on the team building Advanced Installer.
Set the component to always overwrite and write a custom action to add the needed information to the config file.
The only way that seems possible is a custom action to merge the entries in the new file into the existing file, because you want data from the existing a new files. You would also need the upgrade scheduled late (after InstallExecute) so that the upgrade isn't an uninstall of the old product followed by an install of the new product.
If you are doing an upgrade (the WIX_UPGRADE_DETECTED property will be set by a MajorUpgrade element), so update the existing file, otherwise install the new one.
There might be a way to express the updates as an Xml transform, so something in the WiX util:xml tools might help do an update.
I am trying to do a custom action at the time of msi installation. But the dll required for my custom action is depends on other dlls. At the time of installtion it is giving the error like "a dll required for this install to complete could not run".How can I load the dependent dll files for this custom action to run properly.
The code that I am using is
<CustomAction Id='CheckingPID' BinaryKey='CheckPID' DllEntry='ValidateKey' />
<Binary Id ='CheckPID' SourceFile='$(sys.CURRENTDIR)\LicenseKeyClient_32d.dll'/>
<Binary Id ='CheckPID2' SourceFile='$(sys.CURRENTDIR)\curllib.dll'/>
<Binary Id ='CheckPID3' SourceFile='$(sys.CURRENTDIR)\libsasl.dll'/>
<Binary Id ='CheckPID4' SourceFile='$(sys.CURRENTDIR)\openldap.dll'/>
The files that you add in binary table usually get extracted with temporary names during the installation, so your DLL will not be able to locate the other DLLs you add next to it.
A workaround is to add those DLLs as normal files in the Temp system folder and delete them when the installation ends. This has the limitation that you need to set your custom action as deferred, so it executes after the files are installed, thus your DLLs get copied to Temp folder.
I don't know if wix has a support for temporary files, similar with the one present in Advanced Installer, but if not you could try to write a custom action to simulate it. Basically what Advanced Installer does is to extract those files in the Temp folder the moment the MSI is launched, and also deletes them when the installation is complete. This has the advantage that you can use the temporary files and in immediate custom actions, i.e. well before the files from your package are installed.
Despite Bogdan's excellent answer, allow me to add my 2 cents:
It looks like you are dealing with some form of license key validation? The best way is generally to deal with your license keys in the application itself, unless you want it written to HKLM instead of HKCU - in which case you might need the temporary admin rights generally acquired during installation.
You can also open a HKLM key for writing during setup, and write it from the application though this is generally frowned upon security-wise. This allows you to write a single license key for all users directly from the application.
The application features more flexibility and control of the process of registering your license key, and crucially an easy way to run the process again. From my perspective this is almost always needed for a serious application - often due to trial versions with the eventual need to register the license key at the end of the trial period from within the application itself - instead of uninstalling the application and reinstalling, or running the setup in repair / maintenance mode - which seems extremely clunky.
I have described this issue previously in some more detail: Reasons to deal with licensing in the application rather than the setup.
I'll also add that WiX DTF .NET custom actions really simplify this problem by allowing you to embed content into the self extracting custom action package and make them available in the current directory at runtime. Very easy.
But yes, Glytzhkof is correct. Any licensing / DRM done inside of an MSI is easily defeated. It's best to do this in the app or both. For example I've worked at companies where it's a share responsibility. You can enter one now or later. I've also worked at companies where the license key had bits embedded in it that drove feature selection. It gets complicated fast so try not to have to go down that road.
To give you a background - I have a 4 MSI's which comes from our vendor and this has to go to our company servers (we are looking at around 3500 servers). As of now, my counterparts are managing this using vbs, ps1 scripts. But the problem with the script is that everytime an update comes we have to worry about uninstalling the existing package before running the new one and a ton of hardcoding.
I want to automate the whole process (with very less hardcoding) by setting up a WIX script to package all the 4 MSI's together. I read about the WIX bundle and used that to create a single MSI. But now there are lot of a variables to be passed to the 4 MSI's, so I thought of using custom actions to set these variables based on the environment/machine where the MSI is running. But I cant make custom action to work? Am i missing something?
A little bit of googling and I saw something like there are no CustomActions in Bundle? can someone confirm?
Also if there are no CA's what are my options? how can I manipulate the variables to be passed on to the 4 MSI's? Most of them needs to be set based on the machine its being run (like install path, user id's, app pool id's etc).
There is a fourth option, a useful lightweight hack, identified by Vijay Kotecha (see http://vijayskotecha.blogspot.com/2013/07/wix-bootstrapper-custom-action.html),...
Essentially, build an <ExePackage> around a pass-through .bat or .cmd batch file. The batch/command file contains the single line '%*' which re-executes all of the command line arguments as a first class command.
Thus:
<ExePackage ... SourceFile="SourcePath\WixCustomAction.cmd"
InstallCommand="my_custom_action.exe my_custom_parameters" />
<ExePackage ... SourceFile="SourcePath\WixCustomAction.cmd"
InstallCommand="my_next_action.exe my_next_parameters" />
Where WixCustomAction.cmd is a file containing only '%*'.
These <ExePackages> can be placed into the <Bundle><Chain> successively as needed using different InstallCommands as needed.
As I see it, you have three options:
Depending on what information you need, you can use the WixUtilExtension to perform simple tasks such as reading registry keys and performing file searches, which you can then pass the results to your installation packages as properties.
Implement custom actions in the individual installation packages themselves (not in the bundle).
Write your own custom bootstrapper application to determine all the properties you need to set, and then pass them to your installation packages. This is more complex than the #1 and #2, but if your interested the following links should get you started:
introducing managed bootstrapper applications and
write a wpf wix installer
I am in the following situation where I need to remove a component which is marked as permanent.
A previous version of our setup installs a windows service which should be left on the system after the main product was uninstalled.
Now we try to remove the left service and replace it with an updated version. The problem is we have two different component guids out there, because of changing the tools we used to create the msi's.
In my opinion there are three possible ways to achieve the goal:
a) Use a file search to update the files itself.
b) Use a component search and try to find it. If it was not found try to find the other one. If any one found use the upgrade element to upgrade the component.
c) ??? - probably the "best practice" way
Some of my fellows mentioned to only delete the files but this would cause more trouble because of the not unregistered component in the Windows Installer registry.
I don't mentioned CustomActions here because it should be the last option the achieve the goal.
Your best option here is to open your old MSI using InstEd It! or Orca and then copy the Component GUIDs and use them in your new installer.
This way WindowsInstaller will handle the upgrade for you. Obviously this will very painful if you have hundreds of Components that are set as permanent (you only need to bother about the permanent ones), but if it's a just the service element it should be a fairly easy task.
Also make sure your UpgradeCode is transferred across and do a MajorUpgrade so that your old installer is un-installed first.
I am trying to write a Wix3 install for a visual studio add-in.
I have it just about there, but I need reset the plugin by deleting a registry entry. Specifically any value starting with
HKCU\Software\Microsoft\VisualStudio\8.0\PreloadAddinStateManaged\MyAddinName.Connect;
How to a convince Wix to delete any such entries?
You need to use registry element.
http://wix.sourceforge.net/manual-wix2/wix_xsd_registry.htm
This should solve your issue you're having. There is a great WiX tutorial and registry is discussed in chapter called Beyond Files.
Is your issue the need to do a partial match on the registry value. If not, then you might be looking for the RemoveRegistryValue element (nests under Component). If yes, then I would think you'd probably need to create a custom action to search for the registry value(s) to delete and populate the RemoveRegistry table with what you find. I would think a DTF (Deployment Tools Foundation) custom action would a viable option.