I use the Installer Projects extension for visual studio 2015 to distribute my sw written in WPF.
I would like the installer, before the installation, remove all the files in the program folder.
I tried putting true RemovePreviousVersion properties but does not work.
Does anyone know how to fix?
You have to make sure that ALL your project versions inside AssemblyInfo is altered to a new one (greater than the previous one) and also, check that the Installer version it self is altered and a new id is generated (be carefull not to alter the installer id but the upgrade id). It should prompt you when changing the version of the installer that new id will be generated.
Also, because the installer projects are no longer supported directly (see wix), a lot of issues may be raised by the vs extension.
Ypu may also try the Inno setup. It very powerfull and easy to migrate from clasic installer projects.
Good luck.
Related
I'm using Visual Studio 2017 with the Installer Projects extension to make an MSI for my app.
However, when I run the, say 0.2.7 MSI on a system with 0.2.5 already installed, it adds another item to the appwiz.cpl, and leaves the version the same, so that after the 0.2.7 install, it just runs the 0.2.5 exe.
I make sure that the UpgradeCode is the same, the PackageCode and ProductCode are changing with each version and I have RemovePreviousVersions set to true.
My source code is available here. You'll find the installer project in ChromebookGUI/Installer/.
What am I doing wrong?
You can get a list of upgrade codes for installed packages like this: How can I find the Upgrade Code for an installed MSI file?
I have another one that is a bit simpler, but I couldn't dig it up right now. I will have a look later.
Adding this answer to "evolve" it if you provide more follow-up information (to avoid too many comments).
UPDATE: the other answer is here, but I wouldn't recommend that script if you have automatic logging enabled since it will create log files in the temp folder when run.
I've seen several articles online where people show how to create windows setup projects, and then subsequently use the same setup project to deploy updates as in: Updates to setup projects. When performing this sort of install though, the previous version is always uninstalled first before the new version is installed. I'm curious if anyone has found a way to create versioned folders to maintain the previous versions that the user has already installed?
Example:
On first run of the setup.msi, it creates the default directory: [ProgramFilesFolder][Manufacturer][ProductName][ProductVersion] -> C:\Program Files\Manufacturer\Product\1.0.0.
On each next update, it creates new directories as in: C:\Program Files\Manufacturer\Product\1.0.2
There are some cases based on certain configurations where for performing certain functions, we would want to use an older version, rather than the latest version. I know this may sound weird, so I'm not going to get into the reason for why. Just curious if anyone thinks this is doable through regular setup projects.
This is called side by side installation and it's not supported by Visual Studio setup project. Basically, you need to modify the upgrade rules to allow two different versions to be installed on the same machine.
However, each version functions independently of other versions. So version 2.0 shouldn't use files from the version 1.0 folder.
If you want to preserve existing files during an upgrade, you can try this approach: https://web.archive.org/web/20130513032659/http://setupanddeployment.com/installer-concepts/preserve-data-install/
I have created a successful deployment project using Windows Fourms that work as intended but there are two things that need to be solved:-
First: I have to click the setup.exe file in order for the installation to check for the perquisites, and if click the setup.msi it proceeds to install the software directly without checking anything.
Second: When i click on the setup file while the software is already installed on my PC, i get an error message "Another version of this product is already installed. Installation of this version cannot continue. To configure or remove the existing version of this product, use Add/Remove Programs on the Control Panel" while i should get a Repair and Remove options.
Can anybody help me solve this problems ?
As said by Morten, that's how it works. You want to make sure that the prerequisites are (get) installed before your product is installed.
This probably is caused by a rebuild of the deployment package after you installed it. Windows installer notices that you use a different MSI (with a different package code), that contains the same product version. This situation, apparently, is inconclusive enough to leave it up to you what to do with it. The logic of this, I think, is to prevent a "Repair" that in fact installs a different product. Inconvenient for testing, but very much desirable in production environments. If you try to install the same MSI you should get the repair/remove options.
BTW, after building a release, you can right-click the setup project in VS and choose "install". This executes a setup that kindly removes a previous installation with the same version.
i wanna deploy a C# Windows Application project using Setup and deployment project technique
but i don know what should i use
after i open File > New > Project > Setup and deployment > ....
then what ,, what should i do next
In the past I've used the Visual Studio Setup Project or Innosetup for my programs. I prefer to build .msi's over exe's so Visual Studio Setup Project has been my goto for a while now. It is however, very lacking in capabilities. The interface is not intuitive either in my opinion. Every time I build an installer there is a lot of trial and error install/uninstall to get it right. Other's have pointed out WIX and I've looked into it. It appears to be very flexible and since it is open source, we should be able to count on it for the long term.
Here is a recent article about WIX. What I found interesting is the article claims (see link in article) that Visual Studio Setup Project is being End Of Life'd in VS 2010 + NEXT_VERSION. This is a little disconcerting to me. Since I don't want to begin to rely on the new Install Shield "Lite" in VS, I'm going to put effort into learning WIX. I hope it'll pay off in more flexible builds for my applications as well.
All that said, when creating a VS Setup project, I usually use the wizard to put in the initial plumbing. You'll point it at the files you want in the .msi. Typically for me this means the "outputs" of one or more programs in my solution. Any managed assemblies referenced in the programs will automatically get picked up as dependencies and included. Unfortunately unmanaged assemblies don't and I usually have to add them manually using the "File System Editor" mode in the Setup Project UI. Adding shortcuts is a little hokey as well. You right click under the start menu and desktop section of the "File System Editor" mode and select create shortcut. This is all by memory so hopefully I'm getting this right. You will certainly have to test your installer multiple times before you get it just how you want. I like to test under a VM as well.
Finally, the VS Setup project produces a setup.exe and .msi file. Setup.exe is used for detecting and installing dependencies (such as .Net) before unpacking the actual DLL.
When u do this File > New > Project > Setup and deployment >
then right click Application folder> Add > File...and add your app's .exe file and also you can add shortcuts of your app in desktop and program's menu
I would recommend you to go for some tool for creating msi.
I am using WIX
What you need depends on... what you need.
For a large percentage of applications, all you need the installer to do is let the user choose an install location, copy files to a directory structure at that location, and create a few shortcuts. For that, a Visual Studio Installer -> Setup Project is fine. It can handle this basic functionality, as well as installing prerequisites like the .Net Framework redistributables, providing custom install options, and/or writing simple registry keys. The Setup Wizard creates a Setup Project as well, but runs you through a wizard to set up the basics. This is a good option if you've never created an installer before.
If you want this application to be controlled by a larger, more custom install, choose the CAB Project; it will simply pack the necessary files into an archive that is easily accessible from another setup project.
If you are publishing a class library, use a Merge Module. Merge Modules work within install programs themselves, providing files needed for the main application to work.
If you need serious customization, or you want to interface with existing InstallShield logic, I'd get a third-party installer. I've worked with InstallShield before, and it's pretty full-featured, but by the same token, the installers it creates are applications in their own right and can take days or weeks of logic programming to "tweak" to your satisfaction.
I have a Visual Studio setup project that installs an application into the task scheduler and also installs a GUI application to manage some configuration parameters in the registry. This being the case, the setup project installs two different primary outputs (.exe's) as part of the process.
I am getting the following warning when I rebuild the setup project:
Configuration file 'C:\my\App.Config'
is being used to configure all
executables
Is there any way to remove this warning? The suggested MSFT solution apears to be to use a different setup project for each .exe, but I only want the users to have to run one installer. Any suggestions?
There was a <runtime> section in my App.Config file and once I removed this portion of the config file the issue went away.
Maybe you could create an installer that launches all the other installers.
This isn't a particularly helpful on microsofts part is it?
Another idea might be to take their advice and use either no config file or a custom file format so that you avoid this error.
From Choosing a Windows Installer Deployment Tool, it looks like the built-in windows installer maker is essentially deprecated ("Future versions of Visual Studio will not include the Visual Studio Installer project templates.")
This page also recommends InstallShieldLE and Windows Installer XML Toolset. I've just used InstallShieldLE to create an install that includes multiple executables and it appears to have worked (I'll edit this if it turns out it didn't work).
For very complicated installs, I've used NSIS in the past with great success - I'm not sure how much extra effort NSIS requires over InstallShieldLE for simple installs.