Automatically use PackageReference mode if referencing a project that uses PackageReference

[dsplaisted]

I'm not sure how feasible this is, but we have a really poor experience referencing .NET Standard projects from .NET Framework projects today:

• Create a .NET Standard Library project
• Create a .NET Framework Console app
• Reference the .NET Standard Library from the Console app
• Get FileNotFoundException at runtime, depending on what APIs you use

Here are issues I've found that people have filed after running into this:

https://github.com/dotnet/standard/issues/202 https://github.com/dotnet/sdk/issues/757 https://github.com/dotnet/sdk/issues/766 https://github.com/dotnet/sdk/issues/747 https://github.com/dotnet/standard/issues/192

Issue #4488 now tracks a way to opt-in to PackageReference mode without havinng any PackageReference items in a project. However, you would have to know to opt in, so this would still be a common pit of failure.

Ideally, we could automatically detect when a project references another project that's in PackageReference mode, and automatically use PackageReference mode in the referencing project. We might be able to return metadata from one of the targets that's called on project references to help with this. However, by the time we call that target it might be too late- we may need to decide on the restore mode before then. If that's the case then it could still be helpful to generate an error or warning letting people know how to opt in to PackageReference mode.

@nguerrera @rainersigwald for feedback on how we could pass this information between projects as metadata

@rrelyea @emgarten for general FYI

[emgarten]

Restore could determine this, it always finds the full project to project reference graph and the restore style of each project.

However, wouldn't changing the behavior of an existing project to flow all references to it transitively be somewhat unexpected and possibly breaking? There would also be the scenario where the parent project uses packages.config and can't just switch over to using an assets file.

[rainersigwald]

Yeah, sounds like this would be best as a clear error rather than an unexpected behavior change. There may already be metadata on the returned reference items that would be good enough to fuel that in the referencing project.

[rrelyea]

Yes, experience needs thought/design. Consider post RTM.

[dsplaisted]

I wouldn't call this a breaking change for pre-VS2017 projects, because the behavior wouldn't change at all until you reference a project that uses PackageReference, which is something that didn't exist before. Of course since we can't do this for VS 2017 RTM we would still have to think about the impact it would have on projects created with VS 2017.

In general I agree with Rob that we need more thought and design for this. I do think it's important that we try to do something to improve the experience here.

[Code-ScottLe]

Sorry for digging this up again, but do we have a plan to cure this problem yet? Running into this with Standard 1.4 and Unit Test Project (4.6.1) ATM and haven't figured out a good workaround yet.

[cesaralc]

Is there a fix or a workaround for this?

[emgarten]

@cesaralc

<PropertyGroup>
  <RestoreProjectStyle>PackageReference</RestoreProjectStyle>
</PropertyGroup>

[clairernovotny]

This also affects Xamarin projects referencing libraries that use PackageReference but where the Xamarin "head" projects do not have any PackageReferences of their own.

[mattjohnsonpint]

This issue seems to be tracked in dotnet/standard#481

[nkolev92]

Adding NeedsTriageDiscussion.

Given that changing the behavior a few years later would be a breaking change (even if a well meaning one), I don't think we should do this.

Furthermore think of the following scenario.

A (.NET project) -> B (no NuGet project).

msbuild /t:restore A.csproj - restores both projects as PackageReference msbuild /t:restore B.csproj - ??? B wouldn't be restored as NuGet has no clue it should be PackageReference.