VS2017/Vault not binding

[grandavenuesoftware]

Failed again this morning. It's odd, it's almost like it happens every 24 hours. I shut down yesterday, restarted last night and worked without issue.

We see similar behavior. That is, re-installing provides a temporary fix, but the problem recurs eventually. Like adamsbrla, a reboot did not cause the problem to recur after reinstalling.

Next time the issue recurs we will try to re-install with elevated permissions.

Here is other information requested in this thread:
VaultLib.dll is in VS 2017-install-directory \<Edition>\Common7\IDE\Extensions\** (though the extension is currently working correctly). We'll check this again if the issue recurs.

Microsoft Visual Studio Enterprise 2017
Version 15.8.4 (also occurs for 15.8.3)
SourceGear Vault Standard Visual Studio Extension 10.0.1.793

Vault Standard server is version 10.0.1.793

[khosick]

I am having this exact same issue. My question is what changed on 9/10/18 that caused this? Was their an update to the vault? Or visual studio? I would like to roll back those changes instead of re-installing multiple times on multiple machines.

On my machine the SourceGear Vault is not even listed any more in help about visual studio. I had been opening projects with it for years, then I went on vacation on 9/9/18 and when I came back nothing works. I will reinstall and see what happens.

[mmorris]

This now seems to be fixed for us.
Our solution involved running VS2017 in Admin mode ('Run as Administrator')... and then:
"In Visual Studio 2017, uninstall the prior version of the Vault extension. Do this by going to Tools > Extensions and Updates > SourceGear Vault Standard Extension and click the Uninstall button. The uninstall may take a while. It will probably close and reopen Visual Studio as part of the uninstall process." - Paul Andrews (developer on the same team as me)

Then a normal install of the Extension can be performed.

I'll reboot my computer after this to confirm that this solution is stable for us. If I don't write again on this topic, it was stable.

FYI - one of our computers (a virtual machine) did require one additional step: "Not only did I uninstall the prior version of the extension before installing the new version, but I also downloaded and ran the new version of Vault client (version 10.0.2), which is available on the same SourceGear download website, two rows above the VS2017 extension." - Paul Andrews

[Tonya]

Thank you for the update us and providing us with the resolution.

I'm going to close this support case. If anyone continues to experience an issue, please email us individually at support@sourcegear.com.

Thanks,

Tonya

[davenel@leneva.com]

Having a similar issue

Everytime I turn off/on my system including reboots, I get the same set of errors. The solution is to reinstall the VS Extentions. This has been happening for about a month now.

Windows 10 Pro

2018-09-25_1000.png (6.88 KiB) Viewed 19738 times

2018-09-25_1100.png (44.95 KiB) Viewed 19738 times

2018-09-25_1103.png (8.18 KiB) Viewed 19738 times

[Tonya]

This problem appears to be resolved by uninstalling and reinstalling the Vault extensions while running Visual Studio as Admin. The user above reported:

Our solution involved running VS2017 in Admin mode ('Run as Administrator')... and then:
"In Visual Studio 2017, uninstall the prior version of the Vault extension. Do this by going to Tools > Extensions and Updates > SourceGear Vault Standard Extension and click the Uninstall button. The uninstall may take a while. It will probably close and reopen Visual Studio as part of the uninstall process."

Please let me know if this doesn't resolve the issue for you.

Thanks,

Tonya

[grandavenuesoftware]

Please let me know if this doesn't resolve the issue for you.

The problem persists for multiple machines at our site.

We have tried running vsixinstaller.exe as an Administrator, but that didn't do the trick.

Our VS IDE always runs as Administrator. We have tried uninstalling the extension (as Administrator) and re-installing as Administrator, but that didn't last.

Our next attempt is to disable the auto update of the extension.

Our thinking is that the problem seems to have started about the time that 10.0.2 was released in early September. We are running 10.0.1, so a failed auto update might explain the peculiar behavior we have experienced.

An alternative solution would be to upgrade to 10.0.2, but we aren't ready to make that change just yet.

[Tonya]

*** Our next attempt is to disable the auto update of the extension.

Please let me know the outcome.

*** The problem persists for multiple machines at our site.

But not all of them? If so, can you please let me know if they are using a different Visual Studio edition/version? Different operating systems? Or any other differences that may be relevant?

When the problem occurs again, before you reinstall, can you please confirm the following:

Once an extension is installed, it will show up in the VS 2017-install-directory \<Edition>\Common7\IDE\Extensions\<some-nonsensical-hash-name> directory. Searching the VS 2017-install-directory \<Edition>\Common7\IDE\Extensions\** for VaultLib.dll should show.

Is this information being deleted from your system?

Please email this information to support@sourcegear.com. I would like to make separate tickets per customer to keep better track of each issue. So far there doesn't appear to be a "general" resolution to the problem.

Thanks,

Tonya

[grandavenuesoftware]

We will send a separate e-mail, as requested, as well. Posting here for any interested customers following along.

*** Our next attempt is to disable the auto update of the extension.

Please let me know the outcome.

Turning off the auto update feature fixed the problem. The Task Scheduler history shows the update ran overnight (See Task Scheduler Library > Microsoft > Visual Studio > Updates to find the auto update job). When starting VS this morning it successfully connected to SourceGear.

*** Our next attempt is to disable the auto update of the extension.
*** The problem persists for multiple machines at our site.

But not all of them?

No, it impacts all of our machines. Our entire office is running Source Gear 10.0.1 (server and client).

When the problem occurs again, before you reinstall, can you please confirm the following:

Once an extension is installed, it will show up in the VS 2017-install-directory \<Edition>\Common7\IDE\Extensions\<some-nonsensical-hash-name> directory. Searching the VS 2017-install-directory \<Edition>\Common7\IDE\Extensions\** for VaultLib.dll should show.

Is this information being deleted from your system?

This information is not being deleted from our systems. I will include screen shots and additional detail in the email to your support team.

[Tonya]

Thank you for posting the resolution and for emailing us more details. We are currently investigating more into the Auto Update issue within Visual Studio. I will update this thread with more details as they are found.

Tonya

[jclausius]

For anyone that has encountered a problem, a couple of questions so I may forward them to Microsoft's Visual Studio team:

1) What version and edition of Visual Studio or SSDT did this happen on? (Help... About information)

2) Approximately, when did this start happening?

3) If you have multiple users, did this occur on all machines?

4) What version of the Vault for Visual Studio 2017 Extension was originally installed? For example, did you start with Vault 10.0.0, 10.0.1 or 10.0.2?

5) How did you download / install the extension? Did you download the .vsix file from the SourceGear Vault's download page? Did you use the "Tools and Extensions" utility from within Visual Studio?

6) If you downloaded the .vsix file from SourceGear, how did you install it? Did you just double click the .vsix file? Did you install it using VSIXInstaller.exe from an elevated command prompt?

7) If you installed the Vault extension from within Visual Studio, was Visual Studio running under elevated Administrative privileges when the extension was installed?

8 ) When the Vault Extension disappeared, how was Visual Studio last run? Under the normal user or under elevated Administrative privileges?

Thank you.

[grandavenuesoftware]

For anyone that has encountered a problem, a couple of questions so I may forward them to Microsoft's Visual Studio team:

1) What version and edition of Visual Studio or SSDT did this happen on? (Help... About information)

We are running various 15.8.X versions (between 15.8.2 and 15.8.5)

2) Approximately, when did this start happening?

We realized on September 10, 2018 that this issue was impacting multiple users. A few individuals might have experienced the issue a few days earlier, but we don't have an official record of any reports prior to the 10th.

3) If you have multiple users, did this occur on all machines?

Yes.

4) What version of the Vault for Visual Studio 2017 Extension was originally installed? For example, did you start with Vault 10.0.0, 10.0.1 or 10.0.2?

All users are running Vault 10.0.1, both server and client.

5) How did you download / install the extension? Did you download the .vsix file from the SourceGear Vault's download page? Did you use the "Tools and Extensions" utility from within Visual Studio?

We have Vault_VisualStudioExtension_10.0.1.793.vsix on a network share, downloaded from your web site.

6) If you downloaded the .vsix file from SourceGear, how did you install it? Did you just double click the .vsix file? Did you install it using VSIXInstaller.exe from an elevated command prompt?

All users double-click the Vault_VisualStudioExtension_10.0.1.793.vsix file to install the extension. The .vsix file was run as a normal user.

7) If you installed the Vault extension from within Visual Studio, was Visual Studio running under elevated Administrative privileges when the extension was installed?

We did not install the extension from within VS.

8 ) When the Vault Extension disappeared, how was Visual Studio last run? Under the normal user or under elevated Administrative privileges?

All of our VS executables are configured to run as Administrator. So every session of VS on every machine is running with Administrative privileges.

[jclausius]

I heard back from Microsoft regarding the issue. If you are still encountering the problem, they would like to collect some more information regarding the removed Vault extension.

They have asked if you could run vscollect.exe from https://aka.ms/vscollect/ on the machines where the Vault Extension is being removed, and then send the resulting log file at %temp%\vslogs.zip to SourceGear ( email the file to: "support AT sourcegear DOT com" ). We will forward this to MIcrosoft where they say they can check the logs to see if the Visual Studio setup is uninstalling the extension.