I have a setup project for my VB.Net application with the
RemovePreviousVersion property set to True. When I want to publish a new
version of the application, I change the version and say Yes to changing the
product and package codes. I do a "Just for me" install for the new version
and it installs just fine. However, the old version is not removed. It is
still in the Add/Remove Programs list.

Can anyone tell me what am I doing wrong?

Thanks

Steve

Hi Steve,

First of all, I would like to confirm my understanding of your issue. From
your description, I understand that the previous version of your
application is still on the machine even you have set RemovePreviousVersion
property to True. If there is any misunderstanding, please feel free to let
me know.

Based on my research, when RemovePreviousVersion property has been set to
true. We have also to ensure the value of UpgradeCode in both versions.

The installer checks UpgradeCode and ProductCode properties to determine
whether the earlier version should be removed. The UpgradeCode must be the
same for both versions; the ProductCode must be different.

HTH.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

Your understanding of my issue is correct. The upgrade code is the same for
both versions. The product codes are different.

Thanks.

Steve

"Kevin Yu [MSFT]" wrote:

I think that searching this issue in Google some weeks ago I discovered that
there is a bug or issue regarding this: a "Just for me" upgrade can not
remove a previous version if it was installed for Everybody. Is this your
case?

--

Carlos J. Quintero (Visual Developer - .NET MVP)

FAQs, Knowledge Base, Files, Docs, Articles, Utilities, etc. for .NET
addins:
http://groups.yahoo.com/group/vsnetaddin/ (free join)



"Steve Hanna" <gtmw (AT) community (DOT) nospam> escribió en el mensaje
news:A13FE839-5B8A-4DD2-AA5B-215EF72C71E9 (AT) microsoft (DOT) com...

Hello Steve,

As far as I know, "Just for Me" installations should not have this issue
normally. Could you provide us with 2 sample MSI that exhibits this
bahavior? Two simplest samples should be enough. You may add the MSIs to a
zip file and send the zip file as attachment.

If that is not convenient, you may also produce the verbose installation
log of the two MSIs, with the "/l*v" switch:

msiexec /i SetupVersion1.msi /l*v c:\ver1.log

To install the second MSI:

msiexec /i SetupVersion2.msi /l*v c:\ver2.log

Then you may add the 2 log files to a zip and attach it here. We will look
into the logs.

Regards,

Felix Wang
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

Hi Steve,

Thanks for the files. I think I have figured out what is going wrong. This
is an overlooked scenario.

Usually we use product versions greater than 1.0.0. In the MSI generated by
VS.Net, the logic for "RemovePreviousVersions" is to look for all the
products with the same upgrade code with version between 1.0.0 and the
version of the current product. To be more specific, the VersionMin of the
product we search to remove is 1.0.0 and the VersionMax is the current
product version.

In your packages, you are using a version less than 1.0.0 here. So in the
second package the VersionMin we search for is 1.0.0 and the VersionMax is
0.5.219. As a result, no existing product will be qualified with such an
impossible condition. Consequently, the existing version of the product
0.5.218 is not considered a valid previous version and is ignored.

I would suggest that we try a version greater than 1.0.0. Does it help?

Regards,

Felix Wang
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

It's good to have a reason why something isn't working!

This is pre-release code and making it version 1.x.x really isn't
appropriate. We're in beta right now with a few testers. However, from what
you say it seems that there is no other option than to adopt a 1.x.x scheme.
Are there no workarounds on this?

Thanks

Steve


"Felix Wang" wrote:

Hi Steve,

First of all, I would like to check whether modifying the version to more
than 1.0 helps or not.

To workaround this, we can use a Windows Installer Platform SDK Tool named
"Orca" to modify the generated MSI. We can modify the "VersionMin" in its
"Upgrade" table. I hope this helps.

http://www.microsoft.com/msdownload/platformsdk/sdkupdate/

Regards,

Felix Wang
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

Modifying the MinVersion to '0.0.0.0' through Orca works. The problem is in
trying to automate this. When I use wirunsql.vbs from the Platform SDK with
the query "UPDATE Upgrade SET Upgrade.VersionMin='0.0.0.0' WHERE
Upgrade.ActionProperty='PREVIOUSVERSIONSINSTALLED' " I get a popup from wsh
that says "Msi API Error 80004005: Execute, Params 1: 2259 2: mymsi.msi 3:
4:" Getting an 'Unspecified Error' sure doesn't help much. I can update
other columns but not VersionMin or VersionMax.

"Felix Wang" wrote:

When working with a (C#) setup project in Visual Studio, where and how can I
set the 'RemovePreviousVersion' property? And the 'UpgradeCode' and
'ProductCode' properties?
I have been able to make an installation from the resulting .msi file, but
how do I set all the options for automatically removing previous
installations?

"Steve Hanna" wrote: