Empty output

[ElektroStudios]

I have installed Visual Studio 2017 Professional 15.3.4 under Windows 10 x64, but when I launch vswhere I just get an "empty" output like this:

Visual Studio Locator version 2.1.4
Copyright (C) Microsoft Corporation. All rights reserved.

I also tested the vswhere v2.0.2 that ships with my Visual Studio 2017 installation, it returns the same empty output.

What could be the problem?. I tried to test many parameters and examples that are exposed in the vswhere github repo, but every intent returns an "empty" (or true empty) output like that.

PS: I discovered vswhere today, and I have to say that for this reason about it can't seem to detect an official release of Visual Studio and because the author dev. does not want to implement a basic feature like return a fail exit-code which every developer needs to use in the day-by-day, my first impression of this open-source project is a big deception. I hope you understand, with my respectful for the authors of this project, but I can't understand what mind can deny to himself to implement a success/fail return value when developing a console application that evaluates the existance of a file/product/whatever...

Thanks for read! and sorry for my bad English speaking.

[leidegre]

Same result here. Tried various switches as well, nothing. Which is strange because I used the installer and I can open a command prompt with the right environment and run the compilers.

[heaths]

Do you pass -all? Does the header show the installed query version?

As stated, this is designed to be used in scripts in various scenarios. You have empty results. How would an error code make any more difference besides fail a script which you could do based on empty results, whereas some scripting environment would just fail if there were no instances installed which may or may not be a failure depending on the script.

[ElektroStudios]

@heaths Thanks for support. Yes I tried passing the -all switch, I get the same output:

Visual Studio Locator version 2.1.4
Copyright (C) Microsoft Corporation. All rights reserved.

If do you need some info from my side (my O.S configuration) to determine what is happening just tell me what I must provide here.

---

About the exit code debate... well, I really don't pretend to bother any person/author, but for me has no sense to ignore to return a value that indicates a Fail in a CLI program that takes a parametized input query to determine if something is found/installed or its not found. That is considered an abnormal (or missing) behavior for a CLI program.

Please consider that your program should be attempted to use it in this way for example under C# language:

using System.Diagnostics;
using System.Threading;

// Create an instance of the Process class to run vswhere.exe
Process proc = new Process { 
    StartInfo = new ProcessStartInfo {
        FileName = @".\vswhere.exe",
        Arguments = @"-nologo -products Professional -version [15.*]",
        CreateNoWindow = true
        // Check for any version of the Visual Studio 2017 Professional edition installed.
    } 
};

// Run vswhere.exe and wait for its termination.
proc.Start();
proc.WaitForExit(Timeout.Infinite);

// Determine whether Visual Studio is found by evaluating the exit-code returned by vswhere.exe.
bool isVisualStudioFound = (proc.ExitCode == 0); // True if exit code = 0, False otherwise.

if (isVisualStudioFound) {
    MessageBox.Show("Congratulations, Visual Studio is found.");
} else {
    MessageBox.Show("Visual Studio is NOT found.");
} 

PS: I'm not sure whether the syntax of the arguments that I pass to vswhere.exe in the C# sample above are correct since I discovered vswhere few days ago and my first attempt to use it gives me an empty output all the time, then I can't test the program switches, but that doesn't matter, its just a code sample to demonstrate the expected behavior of using/calling vswhere.exe under any high level programming language, that is, evaluating the program's exit-code value.

Regards!

[heaths]

There's no query version in the header, which means the query API is not installed which is why you're getting no results. Try repairing Visual Studio from within the Visual Studio Installer.

If you're using C#, just use the query APIs directly and you can do whatever you want. Why go to the trouble of wrapping an EXE? See https://github.com/Microsoft/vs-setup-samples for examples of how to use the query API directly.

As I've stated, the original use cases vswhere were to not fail so as not to fail build scripts that check return code but already handled cases of missing results (like no registry keys found for older releases). If you want to fork this and change it to your needs, you're certainly welcome to. Someone else in another thread brought up adding a command line option to return a failure which is another option, but I will not be changing the default behavior for return codes. That is a breaking change.

[ElektroStudios]

Hi @heaths, the information you gave me is great, I just didn't knew the existance of the query APIs (I didn't was aware of the internal things that vswhere is using or is depending on).

I did a clean reinstall of VS (a repair didn't worked, I needed to fully uninstall, then install) and now vswhere works as expected. This issue is solved, thanks. However, maybe you would consider to add some error message when query API is not found?, otherwise I think the end-user just will break his head when running vswhere seeying an "empty" output trying to discover what is happening wrong (like me).

Regards.

[heaths]

Consider the scenario: a build script (perhaps cmake to set up the environment where other compilers are available) is running and VS is not installed. Should it err when other compilers are available that it could configure instead? Whether VS is installed or just not the versions required, the behavior is designed to be the same regardless of whether an exit code is returned on error or not (i.e. either always return an exit code, or never do).

Glad it's working for you now. If you can run https://aka.ms/vscollect.exe we can diagnose why the query APIs were not reinstalled during your attempted repair.

[ElektroStudios]

When I noticed vswhere.exe still not working after I "repaired" visual studio (by pressing the Repair button in the VS installer) then I did a uninstall of Visual Studio (by pressing Uninstall in the installer) but I also did some manual cleaning (to try make vswhere.exe work) of all the things I found in my system related to Visual Studio installation, that included cleaning temp folders with installation log files, the installation directory, and main registry keys of Visual Studio, then I installed Visual Studio again. So for all this I'm not sure if after this clean the "vscollect.exe" tool will be usefull for you, but anyways here is the result:

vslogs.zip

Regards!

[heaths]

Thanks. Unfortunately, that didn't contain logs from the original install to see why the query APIs weren't installed in the first place. If you encounter this problem again, please run the collect.exe tool again and use the Visual Studio Feedback Tool in the upper-right of the Visual Studio Installer to attach vslogs.zip so we can diagnose.

[leidegre]

@heaths - well, this doesn't answer my question. I was running into the same issue, vswhere is unable to locate the VS 2017 "BuildTools".

I don't know what to make of this so you tell me, vslogs.zip

Also, I'm working on a tool chain integration as well and it actually does make a lot of sense to ask the vswhere API for info, because the context is neither .NET nor Windows specifically, there's no way we can hook into these service APIs willy nilly. Short of providing my own wrapper, which would be redudant.

[leidegre]

@heaths - also, I think it would be nice if you could provide an example of expected input and as @ElektroStudios said you really have to emit a warning if missing components aren't installed otherwise you think you did everything right and you start wasting time troubleshooting something which was never working, to begin with. Respect the exit code statuses as well. It matters for integration with other language environments.

[heaths]

It won't find Built Tools by default. As called out of the usage text (-?) and on this site in the wiki and in issues like #91 (IIRC), it finds VS be default. Pass -products * to find any product.

[leidegre]

@Heats thanks