I have created an installer package using VS 2010. The setup is working fine.
It includes a msi package file and an external config file.
When I run the installer, and if the software is previously installed, instead of upgrading it, can we just change the config file?
If yes, how ? Please suggest
Regards,
Gagan
How did the config file get copied to the system in the first place?
If it was with custom action code then what might work is a repair of the existing installed product. If the CA condition allows it, then the code will be called again and do another copy of the new file.
Otherwise the answer is no. The supported upgrade in a VS-generated MSI is a RemovePreviousVersions major upgrade.
If I knew in advance that updating the config file separate from the product was going to be a requirement, and it's used by an installed application, then I'd make it app's responsibility to have a choice to load a new config file. By tying the config update to an MSI file the design effectively limits the update choices to what's available in VS setup project updates (RemovePreviousVersions).
Related
I just installed VS2013. As there is no longer the Setup Project, I installed InstallShield LE. I used integrated import wizard and hoped any newer build would automatically update older versions created with VS Setup project. Well, I used to alter the Product Version, which prompted me to alter the Product Code, and that was it. Now I thought this should work with InstallShield as well, so I updated the product version and manually generated the product code. I had the older application installed and tried to reinstall it with this new IS LE setup. And the result is: There are two applications installed, which have exactly the same name and path (it installed in the same directory), but different version. I can really see 2 programs with the same name in "Programs and Features". I checked the upgrade code, it is the same for both. What did I do wrong?
Thanks
Check the installation type, i.e. per user or per machine. It must be the same for both versions, otherwise Windows Installer will skip removing the old versions and you will end up with both versions on your machine.
A verbose log created when you install the new version should also be helpful, you can search for FindRelatedProducts and RemoveExistingProducts standard actions in it, to see why the old version is not removed.
Well finally we were able to solve the problem. You need to place an entry to the Upgrades Path section. Oddly enough You need to do this manually and it's not done automatically by the IS import wizard.
Strange issue, but it is bothering me.
When I tried to deploy msi package is not completely updating the previous version. but the version is been updated in control panel but not UI (changes made in UI is not reflecting).
DetectPreviousVersion = True;
RemovePreviousVersion =True;
Installallausers=true;
The product version is higher number than previously installed version, and changed the product code for each higher version.
upgrade code of the previous installed version and new version are same.
If I remove the previous version manually and then install the latest version then I could see the changes in UI.
Proper versioning of your DLL's and EXE's would prevent this.
File Versioning Rules
At the core of any installer is the actual installation of files.
Determining whether to install a file is a complex process. At the
highest level, this determination depends on whether the component to
which a file belongs is marked for installation. Once determined that
a file should be copied, the process is complicated if another file
with the same name exists in the target folder. In such situations,
making the determination requires a set of rules involving the
following properties:
•Version
•Date
•Language
possibly duplicate question:
but for viewers the answer is adding an extra property to msi package using orca.
REINSTALLMODE=amus
amus-updates the all files on upgrade
omus- updates files that are only changes as installer identifies
refer to original answer here
Older versions of Visual Studio setups used to effectively uninstall all the old files and then install the product and it's files. VS 2008 and later require you to update the file version of files that you want to overwrite in the upgrade.
I created a visual studio setup project. I want this project to install the output from another project into the path given by the user in the installation folder component. That is already working.
Now I want the installer to check if the output is already installed (perhaps that is going to work with the registry?). If it is already installed, some data from the old app.config should be merged into the new app.config (like connection data entries).
Is there a way to do this?
I found custom actions, but the code from my project does not seem to run:
http://msdn.microsoft.com/de-de/library/d9k65z2d.aspx
I simply try to write into the config file:
string path2Conf = "C:\\Program Files\\Proj\\app.conf";
StreamWriter sw = new StreamWriter(path2Conf);
sw.WriteLine("Hallo1298347645");
But after the installation there is not such a string in the config.
Edit: I added the custom action to install.
This is not supported by Visual Studio. Also, you can't do it through custom actions because a Visual Studio setup project doesn't support running actions before the upgrade starts. You would need to backup the original information before installing your new XML.
If this issue is a show stopper, a solution is to use another setup authoring tool which supports XML updates or at least offers more control over custom actions.
If you want a free tool I recommend WiX. It has a steep learning curve but it gets the job done.
I'm setting up an automatic deployment scheme. It would be really handy for us if we could put older msis on the server and have all the clients roll back to previous versions if one of our new releases turns out to be too bug riddled.
Right now, the msi is bitching at me "Unable to install because a newer version of this product is already installed". What kind of property can I set to turn this behavior off? I will gladly do so in my post build vb script.
Thanks
Isaac
Are you using a group policy on your
domain to deploy the msi?
Do you have
a setup project for your msi in
Visual Studio?
Anyhow, I see a solution but not sure if that's right for you...
You need the code matching the old msi that you want to deploy back.
Open the solution matching the code of the old msi.
Using <F4>, open the properties window of the setup project matching the msi,
Increment the Version to a higher number then the one currently deployed. It will ask if you want to change the product code, click Yes.
Rebuild the setup project then deploy.
Since the built msi has a higher version number, it will update the one deployed.
I solved this by changing the DetectNewerInstalledVersion property to false.
It doesn't bitch anymore about this.
Now, with the script that sets the REINSTALLMODE to amus and this setting, my msi will overwrite anything regardless of version.
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.