We currently have 4 installers for our client software:
ClientSetupTest
ClientSetupProduction
ClientUpdateTest
ClientUpdateProduction
The only differences between them are that Setup contains the Crystal Reports redistributable files, and Update doesn't. Test and Production just specifies which environment they run in and the only difference there is one line in the Client.exe.config file.
Dumb, I know, which is why I replaced them all with one installer after getting rid of Crystal Reports. The new installer writes the selected environment out to setup.config, which is referenced by the file attribute (see here).
The "file" attribute is new to the config file with this new installer. The problem I'm running into is that if we modify the Client.exe.config file on an old installation, then run the new installer, the config file never gets updated with the "file" attribute.
Is there any way to force it to update a file? RemovePreviousVersions doesn't exactly work, since it's a different installer, unless I'm misunderstanding something. My current idea, which will probably work, is to add code in the OnBeforeInstall method to rename the old Client.exe.config to a backup file, so it'll always write the new one. Seems like there should be a simpler solution within the installer itself, though. Any ideas?
EDIT: Renaming the old config file to Client.exe.config.old before calling base.OnBeforeInstall() didn't work. It renamed the file, but never wrote the new one.
Windows Installer won't update a modified file.
Nonversioned Files are User Data—If the Modified date is later
than the Create date for the file on the computer, do not install
the file because user customizations would be deleted. If the Modified
and Create dates are the same, install the file. If the Create date
is later than the Modified date, the file is considered unmodified,
install the file.
You have some options:
include a custom action that modifies the file in place. This might be a script or .NET code.
do as you say - move the existing file out of the way. The installer won't stop on it. But you need to make sure it happens in the order you are imagining. You may need Orca to figure out the ordering.
include a custom option to set the create date to be "today". This should be really simple with a scripted custom action, using the Scripting.FileSystemObject. Then Windows installer will overwrite it.
Related
I want to make backup of my application config files. This files are in specified directory. All i want to do is make subdirectory of this directory, and move there this config files on uninstall.
I know that this is possible with WiX custom action, but i think, that there is the simpler way.
I can do this scenario with CopyFile WIX element, but i don't know how to fire it at uninstalling only.
A common way to do this is have the application make a copy of the config file when it first runs, and the copied file is updated and used by the application. The uninstall doesn't remove it (because it didn't install it) but it can be optionally removed with a RemoveFile element or a custom action (and removing with a CA is more straightforward than copying).
One of the reasons this technique is used is that individual config files might be required for each user. In these cases the template installed file is copied by the app to per user locations. Another reason is upgrades and patches. Careless patches and updates can overwrite the original file (because REINSTALLMODE=vamus is used). Also upgrades can be used to deliver updated config files without jumping through hoops figuring out how to preserve the existing config file and yet deliver the new one at install time - the older unchanged template config file can be replaced without impacting current app settings.
Here. Custom action which triggered only on ununstall.
<Custom Action='CREATE_BACKUP' Before='...'>REMOVE="ALL"</Custom>
Using VD2010 Microsoft Deployment Project (MSI)
My application has a database (SDF) that the customer uses to enter all their data, when you uninstall I need to ensure the SDF file remains (so I set Permanet == true) but I also need to ensure that when they install a new version of the application I do not overwrite their copy with the empty/blank DB I install on first use....
Is there anyway to ensure this, or prompt, or something to ensure the customer doesn't loose all their data when they install a new copy?
Thanks,
From a Windows Installer perspective, an SDF is simply a non versioned file. If you make it the keyfile of it's own component and use the default file versioning rules then Windows Installer will evaluate it as such. The behavior will be that if the SDF has the same creation and last modification date, it will get overwritten. If it has a different creation and last modification date it will not get overwritten. This would seem to make sense to me based on the intent of the SDF file.
Another approach would be to install a template SDF file and have the application copy the template to the real database file. This way MSI never knew anything about the "real" SDF file in the first place. It can't service user data that it doesn't know about.
If you include sdf file in the MSI installation it will just copy the sdf database file. It won't provide any error in case of sdf issue. It will complete the installation successfully even if the sdf file is crashed. You can try to provide any check on the db and rollback the installation in case of db error.
I have a setup project. If the user modifies one of the installed files and then un-installs the application, I'd like the file to NOT get deleted by the uninstall (so that when the user re-installs later, the modified file is used rather than the default one that the installer would normally use). Is this at all possible?
Note: Files which have not been edited should be applicable for upgrades/removal.
To prevent uninstall you should mark the files' component as Permanent
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368007(v=vs.85).aspx
Since it is not possible to prevent the setup project from removing modified files when uninstalling, the best approach I have found (as mentioned by Ciprian) is to create a custom action which backs up the modified files before uninstallation, and restores them in another custom action afterwards.
I am using a custom action during install to write a text file to my install directory. When I uninstall, that file is not removed nor is the corresponding install directory. However everything else is uninstalled properly.
I understand the reason that WIX cannot uninstall this file using the uninstaller, I'm just wondering what's the best way to call into a "clean up" action on uninstall which in which I can manually delete the directory/file?
You could include a RemoveFile element in whatever component your text file is most closely associated. When that component is uninstalled, the text file will be deleted as well.
<RemoveFile Id="CleanUpLogFile" On="uninstall" Name="log.txt"/>
You could install an empty text file and then have the custom action write to the file instead of creating it.
In general, I would suggest to stay away from custom actions as much as possible (they can get quite messy when dealing with install, uninstall, patching, repair, etc.) You may want to consider having your application itself configure the file on first run or have an additional configuration app that is executed on first run.
you can always run a console app for example that removes the file through code. You would just add that project only to the uninstall custom actions.
Out of curiosity what is the nature of the text file? In similar situations where the text file is an install log I'd recommend logging to a temp directory or a location that is not under Program Files (such as the Program/AppData folders - C:\ProgramData\Manufacturer\ on windows 7 for instance).
This approach bypasses this issue completely eliminating the need to create custom clean up scripts or actions.
I've added two textbox screens to my MSI installer, and have a custom installer action that hooks back to the application I'm installing to save config settings to the app.config file.
My question is this:
Other than the MSI property screens that allow you to add default text to the MSI custom textboxes, is there a way to have the MSI grab values to put into the text fields from a file or web service, or something? I don't really want these values hard coded into the MSI property screens, and have to recompile and redistribute to change them.
I'd really like to just throw an XML, or CSV file in WITH the installer, and have it read them out of that file, but I haven't seen a way to do that.
Thank you.
With a custom action written in native code (C), you can do anything you want in an installer, as long as the user executing the MSI has permission to do so (which depends on whether it's the UI phase or the execute phase of the MSI - the latter is run by a system service).
What I eneded up doing was using GetPrivateProfileString from importing "kernel32" dll, and sticking a custom written INI file next to the MSI. The property screens I was trying to fill out were removed, and now I can deploy a custom INI file with settings on a per client basis, without having to recompile, and make tedious changes to the installer settings in the project. Email or contact me if you want me to post the code.