Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vswhere needs to be updated #2797

Closed
heaths opened this issue Feb 15, 2020 · 2 comments · Fixed by #2981
Closed

vswhere needs to be updated #2797

heaths opened this issue Feb 15, 2020 · 2 comments · Fixed by #2981

Comments

@heaths
Copy link
Member

heaths commented Feb 15, 2020

I see you are using vswhere 1.0.62 which contains a possible deadlock issue from the CRT I fixed for version 2.1.3. I recommend you update to the latest to make sure this and any other changes are fixed. This also includes a fix to correctly output UTF-8 for JSON despite the console encoding, which will work better for localized installs.

A customer reported an issue where vswhere appears to be deadlocking. They may be using an older version since I see -version [15.0,16.0) which you fixed, but the version of vswhere can still deadlock.

@heaths
Copy link
Member Author

heaths commented Feb 15, 2020

Unfortunately, I can't fix this myself. Once I forked and started digging in, I see you're pulling it from a container. Instead, you might consider just pulling from https://www.nuget.org/api/v2/package/vswhere which will download the latest .nupkg, which is just a ZIP file. You can find vswhere.exe in tools/ at the root of the zip.

If you don't like the idea of pulling from a dynamic version (though I do maintain backward compatibility), you should at least update to the latest version.

@heaths
Copy link
Member Author

heaths commented Feb 15, 2020

I modified externals.sh to actually pull from nuget and used a fixed URL, though it wouldn't have to be. Modifications are to use getopts_long-like functionality (though, simple bash script to avoid dependencies) which don't rely solely on positional parameters (other than source and target) and make the rest of the "flags" more obvious. PR forthcoming.

heaths added a commit to heaths/azure-pipelines-agent that referenced this issue Feb 15, 2020
Version 1.0.62 that was being installed had potential deadlock issues. Resolves microsoft#2797
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant