When I run new installation over existing installed product the installer does not overwrite non EXE and DLL files. For EXE and DLL I can setup version number which defines whether the files will be replaced. But this is not possible for configuration files that contain plain text.
Is there anyway to force the installer replace all files?
Setting DetectNewInstalledVersion to True or False does not have any effect.
RemovePreviousVersions is set to True
The file replacement rules for Windows Installer do not allow user-modified files to be replaced:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa370531(v=vs.85).aspx
The basic problem is that you don't really want a product to install a database file, fill it with data and then destroy it with a product upgrade.
This is most likely what's happening. If you log the upgrade with a command like:
msiexec /I [path to upgrade MSI] /l*vx [path to text log file]
and then search for the file name it will tell you why it didn't replace it.
Another possibility is that the file has been marked as NeverOverwrite in the Component table of the MSI file. This seems unlikely in your case because Visual Studio setups do not provide support for this in the IDE. This applies to the component after it has been installed and cannot be undone - it is a system setting, not an MSI setting.
Related
I have a folder with a 3rd party installer, the folder contains a setup.exe and all its CAB files next to it (and many related folders).
I want to be able to re-package this 3rd party installer into something that I can use in my main application installer as a prerequisite (or as a chained msi package).
I want to not just extract/copy those files on the client machine, but run the installer.
Is it possible to create a MSI from all those files using Installshield? I can't seem to find a project type that would do it.
I'm an InstallShield noob looking for help with a similar problem, but for your needs a Basic MSI Project should be sufficient.
If you are using the Project Assistant wizard, when you the get to the Application Files section you drag-and-drop your various folders and the setup.exe into the INSTALLDIR folder in the wizard and that's pretty much it, I think.
As I recall from other issues I had creating a non-installing MSI of SQL Server, Install Shield will automatically recognize your setup.exe and run that when the .MSI is run.
Problem Scenario: What is your scenario?
Are you taking over the handling and update of an old setup and need to convert it to a proper format?
Are you trying to re-package a third party vendor setup.exe?
Are you trying to get hold of the files inside the CABs? Or just to extract the files so they can be re-packaged some other way. For some reason?
Are you trying to install the whole shebang as easily and reliably as possibly in silent mode?
Some other problem scenario?
Silent Running?: If what you need is to just install silently, then there are command line switches for most setup.exe wrappers that will let you do this, but it is different for every tool used to create the setup.exe file. Installshield's setup.exe files require a silent response file, other tools do it differently. I wrote about Installshield silent uninstall a couple of days ago. And here is a piece on regular silent install and various types of Installshield setup.exe files.
Record response file:
Setup.exe /r /f1”c:\temp\my-answer-file.iss”
Basic silent install:
Setup.exe /s /f1”c:\temp\my-answer-file.iss”
If the setup.exe is a wrapper for an MSI and you have a distribution system to rely on to distribute the pre-requisite components, then it is generally better to extract the MSI if you are in a corporate environment and use the standard features in MSI to run silently (the /QN switch for msiexec.exe):
msiexec.exe /I "C:\Your.msi" /QN /L*V "C:\msilog.log" TRANSFORMS="C:\1031.mst;C:\My.mst"
Quick Parameter Explanation:
/I = run install sequence
/QN = run completely silently
/L*V "C:\msilog.log" = verbose logging
TRANSFORMS="C:\1031.mst;C:\My.mst" = Apply transforms 1031.mst and My.mst (see below).
File Extraction?: Getting the files out of a setup.exe can be challenging, or very easy. It depends what it was built with, and that can be pretty much "anything" - from established deployment tools to proprietary software made by "anyone". To extract files from various types of setup.exe you can find extensive information in this answer:
Extract MSI from EXE (a plethora of links on the subject)
There is also Michael Urman's "hand's-on": Programmatically extract contents of InstallShield setup.exe
Essentially you use setup.exe /stage_only for Installshield Suite executables. And setup.exe /a for Basic MSI and Installscript MSI executables. And setup.exe /s /extract_all for legacy Installscript executables. Clarifications below.
MSI Import: If you manage to extract the files and you see an MSI file there,
then you should be able to import or open that MSI file in
Installshield (or other deployment tools as well).
I'll try a quick "short-list" of extraction options (not sure if that is what you really need):
Already an MSI?: Do you know what that setup.exe contains? Technically it could already be a wrapper containing an MSI file, or it could be the output of some legacy deployment tool and not be a Windows Installer at all. Let's just list a few options:
Administrative Installation: Try to do a setup.exe /a from a command prompt to see if you get an "extract files" dialog. If so, specify an output location and extract all files. This indicates an MSI setup wrapped in a setup.exe
Installscript setup: Try to do a setup.exe /s /extract_all from a command prompt to see if you can extract files from the CABs. This is for Installscript setups. Or try /extract_all:[path] as well.
Installshield Suite Setups: Try to do a setup.exe /stage_only from a command prompt. Lots of elaborate details here.
Advanced Installer: Try to do setup.exe /extract "C:\My work" or setup.exe /x
WiX: Try the following from a command prompt: dark.exe -x outputfolder setup.exe. A WiX setup.exe file can only be extracted using the dark.exe tool from the framework itself. In other words you need to install WiX to extract a WiX setup.exe (as of now).
Wise: Wise is no longer marketed, but many older setups remain. You can try to extract files with setup.exe /X [path].
Repackaging: One way to create an MSI package from older-style, legacy setup.exe installers, is to "capture" the changes done to the system by using an Application Repackaging Tool which monitors changes made to the system whilst a setup.exe is being run.
It is impossible to cover all the different kinds of possible setup.exe files. They might feature all kinds of different command line switches. There are so many possible tools that can be used. (non-MSI,MSI, admin-tools, multi-platform, etc...).
Commmon tools such as Inno Setup seems to make extraction hard (unofficial unpacker, not tried by me, run by virustotal). Whereas NSIS seems to use regular archives that standard archive software can open.
General Tricks: One trick is to launch the setup.exe and look in the 1) system's temp folder for extracted files. Another trick is to use 2) 7-Zip, WinRAR, WinZip or similar archive tools to see if they can read the format. Some claim success by 3) opening the setup.exe in Visual Studio. Not a technique I use.
Some Links:
How do I extract an InstallShield Cabinet file? (this I have never tried)
Uninstall and Install App on my Computer silently
How to make better use of MSI files
That sort of looks like a legacy Installshield setup.exe OR an
Installscript MSI setup.exe. Despite similar appearances these are very different beasts.
I would try the following to determine what you are dealing with:
setup.exe /a
If you get a dialog asking you for an output folder you probably have
an Installscript MSI. Extract the files and then look for an MSI in
the output folder.
If that does not work try setup.exe /s /extract_all or setup.exe /extract_all:[path]. Or try this answer.
Installshield Suite Project: Seeing as you want to distribute this setup as part of your own application deployment I would probably use an Installshield Suite Project - if you have a license for an Installshield version that supports this project type. See screen shot here.
The Silent_Install.bat file (and the associated Silent_Uninstall.bat for uninstall) should contain the command lines you need to use when inserting the package into the suite project. Then you also include your own application as part of the suite installation. Makes sure to test well in all deployment scenarios: install, upgrade, modify, uninstall, patch, etc... There are always surprises.
Repackaging: Alternatively you could re-package the setup with a capture tool instead of running it "as is" - in the existing format. Then you essentially "record" changes made by the setup by monitoring its installation. This works in most cases, but requires significant knowledge to clean up properly. There are also challenges for multi-lingual setups - which this appears to be. This approach has been extensively used in corporations to convert legacy installers to MSI format - and it is still in use. The end result is an MSI that can be installed in silent mode in the standard Windows Installer fashion (which is reliable - much more so than a legacy setup.exe run in silent mode). I would still wrap the captured MSI in a suite project, although you in principle could add it to your own product's MSI. I would not recommend this - for several reasons. Most significantly that you could need to update the runtime setup on its own - without rebuilding your own MSI.
Windows installer is replacing some files while starting the application. This is because these files versions are old as I replace them manually after installation. It's a configuration files.
I googled this issue and found that there's a feature in windows installer "Replacing Existing Files" that do this job based on file version.
Do anyone know how to disable this feature?
Repair is a normal feature of Windows Installer and you can't disable it. Windows keeps a record of the file versions that were actually installed and if it finds that they are wrong, then there are triggers that will cause their replacement. That includes right-clicking the MSI file and choosing repair, or doing a repair from Programs/Features, as well as some automatic entry points. The official way to replace just some files is with a Windows Installer mechanism such as a patch or an update/upgrade of some kind.
You don't say which tool you're using to build your MSI files, but the supported way to tell Windows you don't want it to manage your installed files is to use a null component id:
https://msdn.microsoft.com/en-us/library/aa368007(v=vs.85).aspx
and see the ComponentId description. That means you'll also need to remove them manually at uninstall time. Either you manage them or Windows Installer manages them. Or use a non-MSI setup to completely avoid the issue.
I have a Windows setup and deployment project with which several non-essential files are created. When those files are deleted by the user, the program re-creates them when it's run the next time.
How can I prevent this behavior?
There's no support for this in Visual Studio setups, but the documented way to do this is to have a null Component Id for the files that will be deleted:
https://msdn.microsoft.com/en-us/library/aa368007(v=vs.85).aspx
and see the ComponentId description. So you'd need to edit the MSI file with Orca or a similar tool and set the Ids to null for the files. This can be automated with a post-build script with some MSI SQL and a VBScript or program.
Attempts to make this go away by trying to disable the repair generally fail because not all repairs can be prevented (such as right-click the MSI and repair, or perhaps Programs&Features) and an upgrade (RemovePreviousVersions) may well result in them being re-installed so that Windows can see if they need to be updated or not (which it cannot do if they are absent).
I've been tasked with taking our existing InstallShield based installer and converting it to Install4j. I've been going through the ism file (XML version) trying to figure out what files are being loaded into the installer MSI and then where these files and directories are installed when the MSI is executed. So far I haven't had any luck, we still have a licensed copy of InstallShield 2009, but I don't know where to even look for something like this and the manual has been less that helpful. Does anybody have any ideas?
Open the project up in InstallShield and go to the Files and Folders designer. This will show you the destination view along with the source locations for all the files.
If it's an MSI based project you can build the MSI and then perform an Administrative Installation to extract the files. The extracted structure will mimic how it would have been installed.
Administrative Installation
I have a Windows Forms application with an installer (.msi) already created with Visual Studio. I am now creating a new installer for version 2.0 with the property RemovePreviousVersions set to true.
Now, when I install 2.0 over 1.0 it removes 1.0 and installs 2.0 completely.
Is there a way that I can tell the installer if you find some files already installed (like .xml files used for data) then don't override them?
I am trying to have my 2.0 installer serve the 2 purposes:
Install from scratch for new users
Existing users will upgrade but not lose their customizations
The deployment project in VS does not overwrite files. What happens is that since you have RemovePreviousVersions set to true, when you change your program file version and the ProductCode GUID of the setup project, it will first uninstall the previous version and then will do a clean install of the new version.
To make sure some files don't get overwritten, I usually exclude them from the Content or Primary output files (wherever they are located) and then add them separately to the setup project. Doing this, you can individually set properties for those files. The property you are looking for is called Permanent" that if set to true will never uninstall the file in question, and therefore will never overwrite it with a new version. The only drawback with this is that when you uninstall the product, the Permanent files will not get removed from their target locations, but in my case (usually local DB files), that's a good thing ;)
Cheers!
[edit] The above is true for VS 2008 SP1. Haven't tried it on other versions, so hopefully you are using the same VS version or it works for the version you use.
[edit2] Oh, also you could also use the "Condition" property to achieve something similar. If you do that, make sure that "Transitive" is set to True so the Condition is always evaluated. Haven't tried it with Conditions, but that's another option you could look at. Other than these 2, I think that's pretty much it for VS deployment projects.
When I was in a similar situation what I did was:
The files that were customized by each user and should NOT be touched by the installer were NOT included in the MSI (NOT in the Visual Studio Setup Project). When the app was run for the first time I generated the XML files through the code.
The files that were static (e.g. data that was used to populate Dropdownlists) I included in the MSI and I can update those by building a new MSI with Visual Studio.
Basically don't include customizable files in your MSI project. Create them in code for new users.
I never looked into telling the MSI not to update certain files that are included in the MSI file. The solution I came up with was perfect for me. I don't know if it can be done.
I hope this helps.