Visual Studio 2017 path detection misses version folder

Continua CI Bugs
1

Current logic is:

Finds the path to executable ‘devenv.com’ for VS2017 in the registry key ‘HKLM\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\15.0’ or checks the path ‘%PROGRAMFILES(x86)%\Microsoft Visual Studio\Community|Professional|Enterprise\15.0\Common7\IDE’

Path logic should be:

%PROGRAMFILES(x86)%\Microsoft Visual Studio<strong>2017\Community|Professional|Enterprise\15.0\Common7\IDE<br>

2

Sorry, it also needs to remove 15.0:

“%PROGRAMFILES(x86)%\Microsoft Visual Studio\2017\Community|Professional|Enterprise\Common7\IDE”

3

Hi Geert

Actually the property collector is doing what it is supposed to, the description is wrong. It does look in the paths you suggest, as VS2017 doesn’t write the registry keys we relied on to find the install (I reported this during the beta but nothing has changed for the release). We’ll get the description updated.

4

I’m not 100 % sure about it. I refreshed the properties on the agent quite some times, but it didn’t find it. After customizing the property collector to a Path Finder & customizing the path, it started working.

The Community|Professional|Enterprise had to be changed to professional in my case.

5

Hi Geert,

The code does appear to be looking at the correct path and works correctly in our tests. As well as changing the display test, I’ve added some debug logging to the next version which we plan to release tomorrow. If you are able to send us a debug log after you install this, it will help us to understand what went wrong in your situation.

6

Hi Dave,

Just updated and reverted my override. I want from 124 agent properties to 123 and VS 2017 is no longer available. Reverting back to a custom path finder with this value brings back the VS2017 installation.

I will email you the logs.

7

Here are the logs:

Medium: 10:01:37.062 {T3} [Debug] [Visual Studio PlugIn] Opening registry subkey ‘SOFTWARE\Wow6432Node\Microsoft\VisualStudio\15.0\Setup’
Medium: 10:01:37.062 {T3} [Debug] [Visual Studio PlugIn] Opening registry subkey ‘SOFTWARE\Wow6432Node\Microsoft\VisualStudio\15.0\Setup’
Medium: 10:01:37.062 {T3} [Debug] [Visual Studio PlugIn] Checking for executable under ‘C:\Program Files (x86)’
Medium: 10:01:37.062 {T3} [Debug] [Visual Studio PlugIn] Checking the directory ‘C:\Program Files (x86)\Microsoft Visual Studio\Community\Common7\IDE’ for Visual Studio ‘15.0’
Medium: 10:01:37.062 {T3} [Debug] [Visual Studio PlugIn] The directory ‘C:\Program Files (x86)\Microsoft Visual Studio\Community\Common7\IDE’ for Visual Studio ‘15.0’ does not exist
Medium: 10:01:37.062 {T3} [Debug] [Visual Studio PlugIn] Checking the directory ‘C:\Program Files (x86)\Microsoft Visual Studio\Professional\Common7\IDE’ for Visual Studio ‘15.0’
Medium: 10:01:37.062 {T3} [Debug] [Visual Studio PlugIn] The directory ‘C:\Program Files (x86)\Microsoft Visual Studio\Professional\Common7\IDE’ for Visual Studio ‘15.0’ does not exist
Medium: 10:01:37.062 {T3} [Debug] [Visual Studio PlugIn] Checking the directory ‘C:\Program Files (x86)\Microsoft Visual Studio\Enterprise\Common7\IDE’ for Visual Studio ‘15.0’
Medium: 10:01:37.062 {T3} [Debug] [Visual Studio PlugIn] The directory ‘C:\Program Files (x86)\Microsoft Visual Studio\Enterprise\Common7\IDE’ for Visual Studio ‘15.0’ does not exist
Medium: 10:01:37.062 {T3} [Debug] [Visual Studio PlugIn] No installation path found

As you can see, it’s not adding the year to the path:

%PROGRAMFILES(x86)%\Microsoft Visual Studio<b>2017\Professional\Common7\IDE\

8

Hi Geert

Dave & I think we just figured it out… we’re parsing “15.0” to decimal, I suspect this is a locale issue as I seem to remember you use a comma as the decimal separator in the Netherlands. The reason it would only happen for 2017 is that the registry lookups will fail since the 2017 installer doesn’t write the registry entries (even though I reported it, and they said it would be fixed before release), when they fail we fall back to looking at paths.

The only reliable way to detect 2017 is by checking the standard install paths, if people install in non standard locations we have no way of finding it, and a manual override would be needed.

9

Hi Geert,

Apparently 15.0 = 150 in the Netherlands:

> using static System.Globalization.CultureInfo;
> DefaultThreadCurrentCulture = GetCultureInfo(“nl-NL”)
[nl-NL]
> decimal ver = 0;
> decimal.TryParse(“15.0”, out ver)
true
> Write(ver)
150

We’ve now fixed this code to parse the number using an invariant culture. You can download a new version using the following links:

Continua CI Server Setup (64-bit) v1.8.1.366
Continua CI Agent Setup (64-bit) v1.8.1.366

Continua CI Server Setup (32-bit) v1.8.1.366
Continua CI Agent Setup (32-bit) v1.8.1.366

Thank you for reporting this.

10

Thanks, this fixes the issue, I now have 126 properties, so probably some other stuff has been fixed as well. In the Netherlands, the . is indeed a “visual separator” where the , is a “value separator” (so inverted from US).

I only noticed that it uses devenv.com instead of devenv.exe. I think this is not a real issue, just wanted to inform you about this as well.

11

Great that it is working now. Note that devenv.com, which is a wrapper around devenv.exe, is preferred when running a command line as it delivers its output through standard system streams, such as stdout and stderr.