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.
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 would like to do this.
Check if a registry key exist. If it does, use the value as installdir. If it doesn't, show UI step to select a path and then use it as installdir but also create a registry key and set the value to the given path. The next time I run the installer the registry key should be found and not show that UI step.
Thankful for any help I can get!!
This is quite a common scenario and known within WiX as the Remember Property pattern.
A good explanation can be found on Rob Mensching's blog
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 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
The installer I'm writing using WiX 3.0 uses a RegistryValue element to modify an existing registry value (originally written by our main product). I'm trying to figure out a way to restore the registry value when the user uninstalls my utility. I'd like to avoid using a custom action, but that might be the only recourse? TIA.
I did this. The registry value in question was the application associated to a file extension, but it could be any registry value.
My first idea was to use a "custom action" for install and uninstall to preserve
and restore, respectively, the associated regy state. This
seemed simple enough.
I created a setup project in VS2008 and built the CA's as javascript files. The "on install" script grabbed the existing regy value and stashed it into a well-known place. The "on uninstall" script would look in the well-known place, and then put the value found there, back in the original location.
Easy, right?
There were two problems:
the script that ran during install, to preserve the pre-existing registry value,
runs AFTER the registry has already been updated
with the values for the newly installed thing. So it preserved the new setting instead of the setting that was there before the MSI ran. Not useful.
The script that runs during uninstall, runs AFTER the registry values, and in fact the entire directory subtree,
have been deleted. Including the stashed value. So it had lost its state.
To solve that I wrote another script that
re-orders the custom actions so they run at the proper times.
There's actually one more twist. Obviously, the "Restore" script (on
uninstall) won't work if it is run after the registry entries for the app have been deleted. I can't remember now, why... but I also determined that this script could not run before that. Somehow that wasn't working either.
So, I modified the MSI to run the restore script
twice. In phase 1, it transfers the stashed value to a "parking lot" in the registry.
Then the application's Keys and Values in the registry get deleted, but the parking lot remains. In
phase 2, outside the transactional protection, the restore script retrieves the state from the parking lot, restores
the file association, and then deletes the parking lot.
I can't remember exactly why I needed to do this in 2 steps, but I remember fighting with it for a while before coming up with that solution.
The way it works in development:
set the on install and on uninstall CA's in the VS project
build the VS Setup project
run the post-processing script that modifies the MSI.
When using the MSI, it's a little more complicated than I originally thought but it works.
If you are using WiX, you may have more control over the time and ordering of the steps, so may not need that post-processing step.
Finally, you said you wanted to avoid a CA. To me, CA's are avoided because they are painful to produce in C++, and producing them in .NET is often inappropriate. But, it's pretty simple to use Javascript for CA's. Some people think script is the wrong tool for the CA job. I think that's wrongheaded. I think script is a very good tool for this purpose. And once you can accept script as a good tool, then you don't need to hold your nose about creating a custom CA.
The registry table is incapable of writing a registry value during an uninstall so it is correct that this must be done via custom action. I am of the opinion that using script is bad. Whether you choose to listen is up to you. I can tell you that just the other day I was called into to trouble shoot a situation where some wrote a vbscript CA that was failing because the file system object had been unregistered as part of a security lockdown process.
I suggest C++ or C#/DTF depending on your needs.
Faced with similar issue, need to update the registry value on install and restore to previous value on uninstall.
Is the only solution possible is creating a custom action for this purpose?
I found a extension for wix that has fucntions for this purpose
link to wix extensions