When the popup says it doesn’t detect visual studio, you can still skip and continue. I wonder why it’s not detecting it? We had a hard time trying to find a proper way of detecting - even Microsoft’s suggestion didn’t actually work eye roll

ill look into it a bit further and see if we can find a better way of detecting

@DJ: It's easy to find the Visual Studio 2017 and up: Microsoft: https://github.com/Microsoft/vswhere/wiki/Find-MSBuild

Some quick c# code to use with .NET: https://github.com/ppedro74/Utils/blob/master/FindVisualStudio/Program.cs

using System;
using System.Diagnostics;
using System.IO;

namespace FindVisualStudio
{
    internal class Program
    {
        static string ProcessStart(string fileName, string args)
        {
            var processStartInfo = new ProcessStartInfo
            {
                Arguments = args,
                CreateNoWindow = true,
                FileName = fileName,
                RedirectStandardOutput = true,
                UseShellExecute = false,
                WindowStyle = ProcessWindowStyle.Hidden,
                WorkingDirectory = Path.GetDirectoryName(fileName),
            };

            using (var process = Process.Start(processStartInfo))
            {
                process.WaitForExit();
                return process.StandardOutput.ReadToEnd().Trim();
            }
        }

        private static string GetInstallationPath(string vsWhere)
        {
            var installationPath = ProcessStart(vsWhere, "-latest -products * -requires Microsoft.Component.MSBuild -property installationPath");
            return installationPath;
        }

        private static string GetProductLineVersion(string vsWhere)
        {
            var version = ProcessStart(vsWhere, "-latest -property catalog_productLineVersion");
            return version;
        }


        private static void Main(string[] args)
        {
            var programFiles = Environment.GetFolderPath(Environment.SpecialFolder.ProgramFilesX86);
            var vsWhere = Path.Combine(programFiles, "Microsoft Visual Studio", "Installer", "vswhere.exe");
            if (!File.Exists(vsWhere))
            {
                throw new FileNotFoundException("Cannot find Microsoft Visual Studio's vswhere.exe utility.", vsWhere);
            }

            var version = GetProductLineVersion(vsWhere);
            Console.WriteLine($"Visual Studio Version: {version}");

            var installationPath = GetInstallationPath(vsWhere);
            if (!Directory.Exists(installationPath))
            {
                throw new DirectoryNotFoundException(installationPath);
            }

            Console.WriteLine($"Visual Studio installation Path: {installationPath}");

        }
    }
}

Quote:

With Visual Studio 2017 Update 2 or newer installed, you can find vswhere at %ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe, or to make sure it's always available in your repo see Installing for an option using NuGet.

We went this route and it didn’t work on my computer - because I had a preview of visual studio installed which isn’t in that directory path. Microsoft had numerous suggestions of detecting visual studio. The one which worked for our various installations was a registry check.

apparently with the above individual, the registry didn’t work either. I’ll have to combine a few methods.

everything looks simple from the outside - until you have a hundred thousand+ installations of your software. That’s when you run into things like this lol

@DJ: I agree sometimes the things go out of script easily.

I avoid going through the registry keys, unless is recommended by the vendor. A lot of people blame the changes (keys,  entries are renamed etc), but, that is normal if I own my product is my business and is part of the software evolution. Some products you can break the support contract agreement if you query directly the database, or if you look elsewhere outside of the public API.

Is true story some years ago a "rogue" developer on my team released a Sharepoint integration using a mix of APIs and database queries, everything worked well with multiple clients, until one day the Microsoft Black suits visit one of the customers to follow up on an unrelated support ticket, and they basically used "unsupported" card and left the client hanging, and we had problems too, unfortunately the Rogue developer went to another galaxy ... and the team suffered the consequences.

That does not mean I'm not tempted to do it...

I used the vswhere before and I would say is almost 99% bulletproof, is used with Xamarin, NVIDIA, Intel setups. If you add vswhere.exe to your project (nuget package) you cover scenarios where the tool is not present or have been deleted (broken uninstalls).

The other fallback could be ask the user the visual studio version.

The other reason to avoid registry is due to Visual Studio uses a private exclusive registry keys to store more stuff:  http://www.visualstudioextensibility.com/2017/07/15/about-the-new-privateregistry-bin-file-of-visual-studio-2017/

So the things are getting more complex.

The above post is only part of the "Full solution" for example I have one setup with visual studio 2017 c# installed and Visual studio 2019 with Python and C++, vswhere will return 2019 version,  but my c# is done with VS2017.

If you are generating customized vs version project files, maybe a fallback (ask the VS version) will cover more bases.

Yes - Microsoft has a few pages on how to identify visual studio and we tried them all during testing - the one we went with was with registry. I'm going to combine the two as using only one method apparently doesn't work for all cases.