Problem with installing and removing previous versions after upgrading my setup project to VS2010 by Igor Kondrasovas

Hi,

We have not heard from you in the past 7 days. We will go ahead and close this issue. Please reactivate the bug if the issue persists.

Thank you.

Hi,

We are able to reproduce the issue. After investigation, it turns out the issue is not related to the issue that the hotfix is addressing. The cause is due to the component is being ref-counted so when the second MSI gets installed, it does not remove the old shortcut because it was ref-counted. The workaround is to re-sequence the installation process by doing the following for the 2nd MSI:

1) Use Orca to open the 2nd MSI
2) Browse to the "InstallExecuteSequence" table
3) Find the row whose "Action" column is "RemoveExistingProducts". Change the number "6550" to "1525".
4) Save changes

Please give that workaround a try and let us know if it works for you within the next 7 days.

Thank you.

I have also expirienced this VS2010 SP for setup upgrade installation projects.

According to my tests this hotfix now works for the installation files (configuring the BackwardCompatibleIDGeneration=True) but does NOT work for upgrading (changes of) start menu entries. Consider the following scenario:

(1) Old Setup-Project (MSI):
Start Menu > My Application Folder > My Application V1 (Shortcut to %ProgramFiles%\MyApplication\MyApplication.exe)

(2) New Setup-Project (MSI):
Start Menu > My Application Folder > My Application V2 (Shortcut to %ProgramFiles%\MyApplication\MyApplication.exe)

The installation on a new computer system works fine. But an upgrade of a previous MSI installation will result in the issue that BOTH start menu are displayed (old start menu link "My Application V1" should have been removed)

Start Menu > My Application Folder > My Application V1
Start Menu > My Application Folder > My Application V2

So this hotfix only resolves the issue partly. Please verify.

We haven't heard from you in the last 7 days. We will go ahead and close this issue. Please feel free to reactivate or log a new bug if the issue persists.

Thank you.

We tested the hotfix on VS2010 SP1 on a 64-bit machine and it worked fine. Please let us know which version of VS you're having issues with in the next 7 days and we will look into it.

Thank you.

For VS2010 or VS2010 SP1?

Is there a hotfix for 64 bit systems? The hotfix only works on x86 machines.

The hotfix linked below is for VS2010. The VS2010 SP1 version of this hotfix is uploaded on here: http://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=35848

Please install the hotfix and let us know if you run into any issues.

Thank you.

I am running VS2010 Premium with sp1. Even with the latest version of the hotfix applied my deployment project deletes the registry keys on upgrade.

I migrated a simple deployment project from VS2008 to VS2010 and encountered this bug. As per this issue I built my VS2010 deployment binary again with the following settings:
BackwardCompatibleIDGeneration=True
DetectNewerInstalledVersion=True
RemovePreviousVersion=True
When upgrading to a new revision version (1.2.13 to 1.2.14) when the previous was built with VS2008 these setting did get the files copied over successfully BUT the registry key was deleted.

I applied the hotfix from the link below (the latest version is v3) and tried again. The registry key is deleted.
I even tried updating to a minor version (1.2.13 to 1.3) but no matter what the registry key is deleted

will this ever be fixed?

I applied the new hotfix (V2) and I think it works... if you pay enough attentiion in what you do.
Let me explain with some examples.
For all examples, myProduct setup project has DetectNewerInstalledVersion=True and RemovePreviousVersion=True.

Example#1
Compiled setup project of myProduct (v 1.0) with VS2008.
Installed version 1.0 of myProduct on target machine.
Setup project upgraded from VS2008 to VS2010.
Compiled setup project of myProduct (v 1.1) with VS2010 (BackwardCompatibleIDGeneration=True).
Installed new version (1.1) of myProduct on target machine.
Everything OK.

Example#2
Same as Example#1 but with BackwardCompatibleIDGeneration=False.
Setup failed: registry keys and files were removed.

Example#3
Compiled setup project of myProduct (v 1.0) with VS2010 (patched or not - it does not matter).
Installed version 1.0 of myProduct on target machine.
Compiled setup project of myProduct (v 1.1) with VS2010 (BackwardCompatibleIDGeneration=True).
Installed new version (1.1) of myProduct on target machine.
Setup failed: registry keys and files were removed.

Example#4
Same as Example#3 but with BackwardCompatibleIDGeneration=False.
Everything OK.

So, the difference in setting BackwardCompatibleIDGeneration to True or False depends on what version of Visual Studio you used to compile the setup project that you have already delivered to you customers.

You may have a problem if you have a mix of customers with version 1.0 (VS2008) and 1.1 (VS2010 with bug + Orca workaround) and you want to deliver version 1.2 (VS2010 patched). In this scenario setting BackwardCompatibleIDGeneration works for ugrading one version but not for the other and viceversa.
But this is another story, out of the hotfix scope... I guess.

Anyway, thank you for this hotfix.

Cheers
Max

Hello all,

The updated hotfix is posted on here:

http://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=32676

The BackwardCompatibleIDGeneration property needs to be set to True in order for the hotfix to take effect.

Please let us know within the next 7 days if you run into any issues.

Thank you for your patience.

Hi,

We can reproduce the registry key issue and are looking into posting a new patch. If you are having additional issues, please let us know by tomorrow.

Thank you.

In fact, I still have problems with this issue.

I still don´t know the cause, but I'm experiencing some problems when I run the upgraded version. There is a code protection and licensing solution we use in our app that is throwing an exception at app startup.

I will investigate it in detail and let you know.

Igor.

Hi,

I applied the hotfix and set the BackwardCompatibleIDGeneration property to True, and I can confirm what Chris has written: registry entries are being deleted.
The problem is bypassed if I use Orca to resequence RemoveExistingProducts right after InstallInitialize.

Regarde,
Max

Hello,

There is still an issue with this hot fix. The registry entries are being deleted on an upgrade from a vs2008 built msi to a vs 2010 built msi. The delete of the registry keys happens between the install phase and the commit phase.

Cheers

Chris

Hi,

I have just tested the hotfix and now it is working great. Thank you very much Microsoft for the support and making VS 2010 such a great product.

Regards,

Igor.

Hi,

After applying the hotfix, you'll need to manually set the BackwardCompatibleIDGeneration property on the setup project to true and then rebuild your project. Can you give that a try?

Thank you.

I have implemented the below patch but still problem exist. The installer doesn't remove old version of the program and after installation of new version of program it open the old version of application..

Please help with this critical issue.

Hi,

Thank you for your patience. The hotfix is now posted on Connect: https://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=32676&wa=wsignin1.0

We will leave this bug active for another 7 days in case if you have any questions or run into any problems.

Thank you.

Hi,

Thank you for reporting this issue. We're looking into releasing a hotfix for this problem. Stay tuned for further updates.

Thank you.

The two workaround do not completely resolve our issues, although we have a similar situation. Ours is a VS 2008 Web Setup project changed to a VS 2010 Web Deployment project (because .Net 4 doesn't currently support Web Setup projects).

After implementing the MoveREP.js Post Build Event, our content files are no longer deleted, but we still have 3 dlls that end up missing after an upgrade. We then tried running FixCompIds.exe, but we still end up with these same 3 dlls getting deleted instead of having them replaced with the newer versions (even though FixCompIds did change their IDs). All 3 are outputs of projects in our solution that are included in the deployment project as "Primary output from".

Is there some other workaround that will help our situation?

It looks like there are a few errors around MSI project in VS2010. We have this installation issue along with VS2008 upgrade issue (https://connect.microsoft.com/VisualStudio/feedback/details/552799).

To solve the problems in a timely manner and help customers to plan for the development effort, can Microsoft give us a commitment when these problems can be fixed?

I am very happy I abandoned VS setup projects and turned to WIX right away when I faced this problem in May, instead of waiting for Microsoft to fix this problem; otherwise my new product release still wouldnt be available.
It is sad that Microsoft pays so little attention to customers; smaller companies could not afford to provide such a poor support...

dear anonymous microsoft person: on 7/7 i posted a comment regarding the workaround. also on 7/7 you asked for a download link which i provided one day later.

now, 7 days later, there is still absolutely _zilch_ response from you. not even an acc that you've got the files. thus, i just pulled the files from our webserver. if you're still intrested in taking a look, you can contact me at tw@die.de and i'll provide the files again.

however, and i'm neither the only one, nor is this the first time stuff like this happens, i'd like to add how unbelievable bad the communictaion using connect is. i (and i'm certainly not the only one) really mislike...

- the way this is handled anonymously
- the way this is handled without any commitment
- the way everyone (of your customers) are not told anything about possibly dates or repsonse times
- the way this whole thing is making any plany absolutely impossible

me, i really can't wait if you ever feel good enough to respond or do anything about this problem. (that you created in the first place.)

i will simply stop using setup and deployment projects (and i will remember it was microsoft who made me abandon all the work that we have invested into our setup project for the last 5 years. thank you very much.)

We created a quick .NET 3.5 console application to automatically update the component ids in the newly built Windows installer package. It worked on the two projects we tested it on. It can easily be incorporated into a post build step if desired. It takes 2 command line arguments:

1. Full path to the previous/old MSI.
2. Full path to the current/new MSI.

Here is the link:

http://www.splitware.com/downloads/fixcompids.zip

vs2008: http://www.die.de/downloads/vs2008.zip
vs2010: http://www.die.de/downloads/vs2010.zip

pls. let me know when you downloaded the stuff so i can take it down from the site.

Actually, that would be helpful if you could provide a download link for the vs2008 version setup, and the vs2010 version setup, so I can look in your MSI to see your exact situation.

Thank you.

forgot: i can provide a download-link for the "vs2008 version" setup and the "vs 2010 version" setup if that is any help.

The workaround only works partially for me. I have the following situation (which i guess isn't all that uncommon...):

The previous version of my app was build using vs 2008. The setup was done as a setup/deployment project in vs2008. The current version is build using vs2010. (New Version/Product code, same Upgrade code.).

This thing is deployed in the vs2008 version on several thousand customers machines.

Now when i install the new version on a machine that has the previous version installed, the workaround seems to work somewhat. that is, it appears that after setup all files are where they are supposed to be. (i'm installing ~5000 files, so i'm not 100% sure, but it _does_ look ok, and the software appears to run ok.)

However, something is still wrong with the advertised shortcuts in start menu. when i try to run the software by starting it from its on-disk location in explorer, everything looks ok. when i try to run it from the shortcuts on the start menu, windows installers starts and attempts to "repair" the installation.

any suggestions as how to circumvent this ?

WM_THX
-thomas woelfer

Thanks for reporting this issue. After an in-depth investigation, this is a bug in setup projects. To mitigate the worst effects of the bug for now, a workaround is to re-sequence the "RemoveExistingProducts" action to be after InstallInitialize.

Note this workaround will fix the "upgrading removes all files" behavior, but other issues will remain - particularly, files shared between two setups will not work properly (if you have setupA built with VS2008, and setupB built with VS2010, two products which can exist on the same machine at the same time, and both of which install file foo.dll to the same directory: then when uninstalling either A or B, foo.dll will be removed, even though the other still-installed product will be broken because of it). If you do find yourself in this situation, repairing the broken product will correct the situation.

Here's an example of how you can workaround the worst parts of the issue automatically after each build with a post-build script. To do so, you would put the following text into a file next to your .vdproj called "moveREP.js", and then and then set your "PostBuildEvent" property (in the property grid) to exactly the following string, to run it after every build - cscript.exe "$(ProjectDir)\MoveREP.js" "$(BuiltOuputPath)" (example script text below).

Please apply the workaround and let us know if it works for you. In the case that it does not, please attach a sample repro project and we'd be happy to take a look. Thank you.

// MoveREP.js <msi-file>
// Performs a post-build fixup of an msi to run RemoveExistingProducts after InstallInitialize

// Configurable values
var newSequence = 1525;

// Constant values from Windows Installer
var msiOpenDatabaseModeTransact = 1;

var msiViewModifyReplace        = 4

if (WScript.Arguments.Length != 1)
{
    WScript.StdErr.WriteLine(WScript.ScriptName + " file");
    WScript.Quit(1);
}

var filespec = WScript.Arguments(0);
var installer = WScript.CreateObject("WindowsInstaller.Installer");
var database = installer.OpenDatabase(filespec, msiOpenDatabaseModeTransact);

var sql
var view
var record

try
{
    WScript.Echo("Updating the InstallExecuteSequence table...");

    // Modify the Control_Next of BannerBmp control to point to the new CheckBox
    sql = "SELECT `Action`, `Sequence` FROM `InstallExecuteSequence` WHERE `Action`='RemoveExistingProducts'";
    view = database.OpenView(sql);
    view.Execute();
    record = view.Fetch();
        if (record.IntegerData(2) == newSequence)
        throw "REP sequence doesn't match expected value - this database appears to have been already modified by this script!";
        if (record.IntegerData(2) != 6550)
        throw "REP sequence doesn't match expected value - this database was either already modified by something else after build, or was not produced by Visual Studio 2010!";
    record.IntegerData(2) = newSequence;
    view.Modify(msiViewModifyReplace, record);
    view.Close();

    database.Commit();
}
catch(e)
{
    WScript.StdErr.WriteLine(e);
    WScript.Quit(1);
}

Thanks for your feedback. We were able to reproduce the issue you are seeing. We are routing this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)