DiscoveryType.VisualStudioSetup no longer works when upgrading to net60 explicitly targeting net60-windows/win-x64
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- csharp
- Domain
- build-system, devtools
Research direction
Start with MSBuildLocator.QueryVisualStudioInstances and the DiscoveryType.VisualStudioSetup and DiscoveryType.DeveloperConsole paths, then compare behavior when targeting net60, net60-windows, and win-x64. The issue is resolved when supported functionality is available in an appropriate package, or unsupported discovery fails clearly and the package documentation explains the limitation and alternatives.
Written by the indexing model from the issue text.
Description
We are in the process of upgrading our test infrastructure to net60 and we are using MSBuildLocator.QueryVisualStudioInstances(new VisualStudioInstanceQueryOptions { DiscoveryTypes = DiscoveryType.VisualStudioSetup }) to get the location of msbuild.exe, which we need to perform out of process roundtrip testing of our decompiler (as can be seen here).
Could you please provide a Windows-specific build of this nuget package, which works with net60 and up and includes the FEATURE_VISUALSTUDIOSETUP features?
Either that, or:
- Fail fast with a
NotSupportedExceptionifDiscoveryType.VisualStudioSetuporDiscoveryType.DeveloperConsoleare used, stating the reason - I had to decompile the nuget package to understand what was going on, - Update the documentation and package description accordingly so that it says that (more than) half of the features are not available when using the nuget package with net or netcore
- and provide guidance on how to get the functionality, if it is not/no longer available using this official package - this is especially important because the classic framework will fade away sooner or later, leaving us in this "broken" state.
Alternatively, %PROGRAMFILES%\dotnet\sdk<version>\ could simply include a runnable msbuild.exe for people, who need it. But I guess, this would be a request for the dotnet runtime repo. I am just wondering, why nobody at Microsoft thought this might be useful and included it out of the box.
Thank you very much!
- Dominant language
- C#
- Stars
- 262
- Forks
- 91
- Avg merge
- 11d 22h
- Merged PRs (30d)
- 3
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/MSBuildLocator
-
Difficulty 3/5 1-2 days Newbie friendliness 52/100
microsoft/MSBuildLocator#390 · 1 reaction ·
-
Difficulty 4/5 3-5 days Newbie friendliness 64/100
microsoft/MSBuildLocator#389 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
microsoft/MSBuildLocator#380 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 48/100
microsoft/MSBuildLocator#377 ·
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
microsoft/MSBuildLocator#371 · 1 comment ·
All issues in microsoft/MSBuildLocator
Similar issues
-
untriaged
Difficulty 1/5 Under an hour Newbie friendliness 88/100
dotnet/dotnet-api-docs#13095 ·
-
area-deployment area-integrations triage:bot-seen
Difficulty 2/5 Half a day Newbie friendliness 86/100
-
type/automation type/tech-debt
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 90/100
newrelic/newrelic-dotnet-agent#3850 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
LuckyPennySoftware/AutoMapper#4660 ·