When using Visual Studio 2010 or any other version to create msi setups you can define prerequisites that need to be installed before the application will install. For most .NET applications this will be at least the .NET Framework itself. But from version 3.5 on there are two editions of this framework: the Client Profile and the Full Framework.
I created a setup and changed the prerequisites from Client Profile to the Full Framework. When testing this on a virgin machine the setup told me that I need to install the .NET 4.0 framework (that’s right) but then it directs me to the download of the Client Profile only.
To fix this, you have to change the InstallUrl of the .NET Framework Launch Condition:
- right-click on the setup project in solution explorer and choose View –> Launch Conditions
- here you will find a Launch Condition for the .NET Framework
- select this Launch Condition and open the Properties Window
- there you will find the InstallUrl property
For the full .net 4.0 Framework change this URL to http://go.microsoft.com/fwlink/?LinkId=186913
For the Client Profile of the .net 4.0 Framework the URL can stay as it is: http://go.microsoft.com/fwlink/?LinkId=131000
Visual Studio 2005 had a known issue with the setup project and the
RemovePreviousVersions option if the version number of your software is less than 1.0. This was a problem for me every time I released a new version of PhotoTagStudio. Like most small open source projects I won’t call it 1.0 (the current version is 0.7).
I described the problem and a workaround using the tool orca.exe. Every time I build a new setup I had to patch the setup. Last week I switched my PhotoTagStudio project to Visual Studio 2008 and created a new release. While patching the created msi I discovered that there is no need to do it that way any more. The problem seems to be fixed in the Visual Studio 2008 release!
Great work Microsoft!
[Edit: this seems to be solved in Visual Studio 2008. See this article]
In theory if you create a setup project within Visual Studio, you can set the
RemovePreviousVersions to force the created setup to uninstall all previous versions of the same software already install on the target computer. This is a very useful option, but it does not work under all circumstances. But before I go into the problems a brief overview how it should work:
Besides the RemovePreviousVersions flag there are two further properties:
UpgradeCode must be the same for all setup projects (that is for the old versions and for the new version). The installer uses this
UpgradeCode to detect an older version of the software. The
ProductCode must be different for every version, this is uses by the installer to detect different versions of the same software . If you change the Version of an installer Visual Studio creates a new
This works the way described here in the same way described in the product documentation as long as you do not use a Version number below 1.0. If you name your beta and prerelease version something like 0.5 the installer does not recognize an previous version and will not uninstall it, but installs the new version side by side which can be a problem for you installation e.g. if it will be installed in the same directory.
Unfortunately this seem to be a known issue since 2004 or earlier and is not fixed in Visual Studio 2005. The installer looks only for previous Versions greater or equal 1.0 but not for versions less than 1.0.
But there is a workaround. You have to patch the MinVersion in the created msi-file with a tool called orca.exe.
- Download the Windows Platform SDK – about 400 MB
- Install it – Full install is about 1 GB but you only need the MSI-SDK parts, so choose the custom installation.
- In the directory of the SDK you will find an orca.msi – install it
- Start the orca.exe and open your created msi
- Got the Upgrade-Table
- Look for the 220.127.116.11 in the
VersionMin-field and change it to somethink like 0.1.0.0
- Save the changes to the msi