NuGet VSIX should ship Microsoft.Build.NuGetSdkResolver manifest

[rainersigwald]

It's possible to install copies of Visual Studio that do not include NuGet, but do include MSBuild. One case is installing just the C++ Build Tools workload. If you then use that MSBuild to build an SDK-style project, you can get a confusing error

confusing error

Microsoft.Build.Exceptions.InvalidProjectFileException: Could not load SDK Resolver. A manifest file exists, but the path to the SDK Resolver DLL file could not be found. Manifest file path 'C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\SdkResolvers\Microsoft.Build.NuGetSdkResolver\Microsoft.Build.NuGetSdkResolver.xml'. SDK resolver path: C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\CommonExtensions\Microsoft\NuGet\Microsoft.Build.NuGetSdkResolver.dll  g:\Projects\csharp-research\ex_0_001_fibonacci\ex_0_001_fibonacci.csproj
   at Microsoft.Build.Shared.ProjectFileErrorUtilities.VerifyThrowInvalidProjectFile(Boolean condition, String errorSubCategoryResourceName, BuildEventFileInfo projectFile, Exception innerException, String resourceName, Object[] args)
   at Microsoft.Build.BackEnd.SdkResolution.SdkResolverLoader.TryAddAssemblyFromManifest(String pathToManifest, String manifestFolder, List`1 assembliesList, ElementLocation location)
   at Microsoft.Build.BackEnd.SdkResolution.SdkResolverLoader.FindPotentialSdkResolvers(String rootFolder, ElementLocation location)
   at Microsoft.Build.BackEnd.SdkResolution.SdkResolverLoader.LoadResolvers(LoggingContext loggingContext, ElementLocation location)
   at Microsoft.Build.BackEnd.SdkResolution.SdkResolverService.Initialize(LoggingContext loggingContext, ElementLocation location)
   at Microsoft.Build.BackEnd.SdkResolution.SdkResolverService.ResolveSdk(Int32 submissionId, SdkReference sdk, LoggingContext loggingContext, ElementLocation sdkReferenceLocation, String solutionPath, String projectPath)
   at Microsoft.Build.BackEnd.SdkResolution.CachingSdkResolverService.<>c__DisplayClass3_0.<ResolveSdk>b__0(String key)
   at System.Collections.Concurrent.ConcurrentDictionary`2.GetOrAdd(TKey key, Func`2 valueFactory)
   at Microsoft.Build.BackEnd.SdkResolution.CachingSdkResolverService.ResolveSdk(Int32 submissionId, SdkReference sdk, LoggingContext loggingContext, ElementLocation sdkReferenceLocation, String solutionPath, String projectPath)
   at Microsoft.Build.Evaluation.Evaluator`4.ExpandAndLoadImportsFromUnescapedImportExpressionConditioned(String directoryOfImportingFile, ProjectImportElement importElement, List`1& projects, SdkResult& sdkResult, Boolean throwOnFileNotExistsError)
   at Microsoft.Build.Evaluation.Evaluator`4.ExpandAndLoadImports(String directoryOfImportingFile, ProjectImportElement importElement, SdkResult& sdkResult)
   at Microsoft.Build.Evaluation.Evaluator`4.EvaluateImportElement(String directoryOfImportingFile, ProjectImportElement importElement)
   at Microsoft.Build.Evaluation.Evaluator`4.PerformDepthFirstPass(ProjectRootElement currentProjectOrImport)
   at Microsoft.Build.Evaluation.Evaluator`4.Evaluate(ILoggingService loggingService, BuildEventContext buildEventContext)
   at Microsoft.Build.Evaluation.Project.Reevaluate(ILoggingService loggingServiceForEvaluation, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext)
   at Microsoft.Build.Evaluation.Project.ReevaluateIfNecessary(ILoggingService loggingServiceForEvaluation, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext)
   at Microsoft.Build.Evaluation.Project.Initialize(IDictionary`2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext)
   at Microsoft.Build.Evaluation.Project..ctor(String projectFile, IDictionary`2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectCollection projectCollection, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext)
   at Microsoft.Build.Evaluation.ProjectCollection.LoadProject(String fileName, IDictionary`2 globalProperties, String toolsVersion)
   at OmniSharp.MSBuild.ProjectLoader.EvaluateProjectFileCore(String filePath)
   at OmniSharp.MSBuild.ProjectLoader.BuildProject(String filePath)
   at OmniSharp.MSBuild.ProjectFile.ProjectFileInfo.Load(String filePath, ProjectLoader loader)
   at OmniSharp.MSBuild.ProjectManager.LoadOrReloadProject(String projectFilePath, Func`1 loader)

This happens because MSBuild ships an XML manifest for the NuGet SDK resolver in its VSIX:

https://github.com/Microsoft/msbuild/blob/50639058f947ef3b21075cb110f06913124d2942/src/Package/MSBuild.VSSetup/files.swr#L60-L61

But the file pointed to by that manifest is delivered by the NuGet VSIX:

https://github.com/NuGet/NuGet.Client/blob/d9a35fdd6a5fd39876358ec8b759766d112d0592/setup/Microsoft.VisualStudio.NuGet.BuildTools.swr#L9

And there's no package-to-package dependency from MSBuild to NuGet so that could be a dangling reference.

I can see two ways to solve this: either establish that dependency or change the ownership of the manifest file from MSBuild to NuGet. I think the latter is easier but I'd be open to the former.

This was reported as OmniSharp/omnisharp-roslyn#1311.

[AndyGerlicher]

I agree it makes sense that the component that inserts the resolver should be responsible for the xml manifest telling MSBuild where it is. But also I think we need to keep in mind that a core set of NuGet (resolver + NuGet tasks) is a dependency of MSBuild now (tasks in our common targets require NuGet to build). Ideally if there's a package that has that core set of NuGet it should be a dependency of the Microsoft.Build package and pulled in whenever MSBuild is installed. Personally I would rather see the effort go there so there's never a scenario where MSBuild.exe exists in a VS install but NuGet.*.dll (including the resolver) doesn't.