dotnet / NuGet.BuildTasks

The build tasks used to pick up package content from project.lock.json.
MIT License
45 stars 61 forks source link

Default to MSBuildProjectExtensionsPath when looking for a default assets file #83

Closed nkolev92 closed 4 years ago

nkolev92 commented 4 years ago

Fixes: https://github.com/dotnet/NuGet.BuildTasks/issues/82

See: See: NuGet/NuGet.Client#2131 and microsoft/msbuild#1603 for context.

Basically BaseIntermediateOutputPath is not ideal because that's not what current NuGet uses. MSBuild imports the generate nuget.g.props/targets based on MSBUildProjectExtensionsPath and that's NuGet writes.

This affects customers such as: https://developercommunity.visualstudio.com/content/problem/970381/compiling-does-not-find-nuget-packages-that-were-j.html

I'd be happy to add a test if I can get pointers to it.

tmeschter commented 4 years ago

@nkolev92 Can you think of any customers that might be negatively impacted by this?

nkolev92 commented 4 years ago

@nkolev92 Can you think of any customers that might be negatively impacted by this?

Unlikely. The MSBuild targets have always relied on MSBuildProjectExtensionsPath for importing the Nuget.g.props. https://github.com/microsoft/msbuild/blob/2cee6d0201eb47e512d51bf2b52685d8b7f5480e/src/Tasks/Microsoft.Common.props#L41-L60 So as long as NuGet & the MSBuild imports are consistent, things should just work.

What this does fix, is the first time restore in VS scenario, because the props are not there to "auto-correct" the assets file location at project load time, so it will make that experience a bit better.