Improved UX for nuget developers - referencing project as nuget

[JanKrivanek]

Summary

V-Next continutation of https://github.com/dotnet/msbuild/issues/8398 Add option to to treat referenced project (ProjectReference) as NuGet package (PackageReference).

This way the package developer could have a solution containing the project producing the package as well as project integration testing the package, that is utilizing not only the actual code, but as well other possible assets (analyzers, msbuild .props/.targets files). This can currently be achieved only via additional steps (packing the project, flushing nuget caches, adding the location with build package to sources, referencing the build package).

Related:

• https://github.com/NuGet/Home/issues/6579
• https://github.com/dotnet/sdk/issues/1151
• https://stackoverflow.com/questions/42773815/net-core-csproj-global-json-projects-equivalent

[jrdodds]

... as NuGet package (PackageDependence).

Should that be PackageReference?

[atrauzzi]

This would be extra nice if the references could be to projects in other solutions as well. Thereby enabling multi-repo scenarios where packages are built in a separate code repository.

[JanKrivanek]

This would be extra nice if the references could be to projects in other solutions as well. Thereby enabling multi-repo scenarios where packages are built in a separate code repository.

The solution (.sln) boundary is usualy not a big deal for msbuild (as it operates on projects and their dependencies) - as soon as there is no additional build logic, that is not a part of the said project (e.g. custom build script used to produce nuget). That happens as well - and in such case some specific conventions would need to be prescribed and followed (something along the lines of https://github.com/dotutils/MSBuild.BuildLink/blob/main/docs/buildlink.json.md).

All that being said - this topic is currently below the focus line of the team. So no promisses (but stay tunned ;-))