Update/uninstall leaves VS2013 extension behind

[cremor]

If you uninstall code contracts, either manually or by installing a new version, the VS2013 extension stays installed or stays at the old version. The whole folder C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\Extensions\Microsoft\CodeContracts isn't removed.

[reitzmichnicht]

I can confirm this.Happens on every update in VS2013.4

[icnocop]

This causes VS2013.4 to indicate that there's an update to the Code Contracts for .NET extension even though the latest version is installed.
For example:
Current Version: 1.7.11106.10
New Version: 1.7.11202.10

In this case, there's a directory for both versions in that folder:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\Extensions\Microsoft\CodeContracts\1.7.11106.10
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\Extensions\Microsoft\CodeContracts\1.7.11202.10

For reference, see the following (and its links):
http://stackoverflow.com/questions/27914824/code-contracts-version-does-not-updated

Thank you.

[tom-englert]

This still happens with 1.9.10714.2

[federicoce-moravia]

Same here. This confuses VS a great deal, misreporting the version number unless you remove the folder(s) and touch the extensions.configurationchanged file.

It may be related, I've noticed the install/repair/uninstall process takes a suspicious amount of time, the progress bar getting stuck at about 80% as if it was wrestling against a file in use or something similar.

[sharwell]

It may be related, I've noticed the install/repair/uninstall process takes a suspicious amount of time, the progress bar getting stuck at about 80% as if it was wrestling against a file in use or something similar.

This is calls to devenv /setup. Unfortunately not avoidable when you manually install extensions (e.g. use MSI instead of just having the user open a VSIX).

[tom-englert]

Yes, devenv /setup is very slow.
However the installer calls devenv /setup while the old extension is still there. The installer should first remove the old version, then call devenv /setup.

[sharwell]

@tom-englert Yes that is correct. My comment was only meant to clarify that the "hang" isn't the problem here; failing to remove the extension files is.

[tom-englert]

@sharwell

This is calls to devenv /setup. Unfortunately not avoidable when you manually install extensions (e.g. use MSI instead of just having the user open a VSIX).

I did not look into details how the extension is installed, but packing the VSIX into the MSI and just call the VsixInstaller.exe as a custom action could simplify the installation, fix issues with left-behind versions and speed up the installation. ❔

[sharwell]

@tom-englert Eventually the best possible experience would be an installation that only required VSIX and NuGet. As long as the MSI is used, we'll be fine as long as it properly detects installed versions and knows how to remove itself (both of which should now be in place).

[tom-englert]

@sharwell it was just an idea - however never change a running system 😄