Adding both Project and Package references to .Net Core SDK based project shows permanent dependency warning, when PackageReference Version range specified

[YakhontovYaroslav]

This might be somehow related to #2835

Steps to reproduce:

1. Create project A:

<Project Sdk="Microsoft.NET.Sdk">  
  <PropertyGroup>
    <TargetFrameworks>net462;netstandard2.0</TargetFrameworks>
    <GeneratePackageOnBuild>true</GeneratePackageOnBuild>
  </PropertyGroup>

  <PropertyGroup>
    <Version>1.2.6</Version>
  </PropertyGroup>

</Project>

2. Create Project B:

<Project Sdk="Microsoft.NET.Sdk">
  
  <PropertyGroup>
    <TargetFrameworks>net462;netstandard2.0</TargetFrameworks>
    <GeneratePackageOnBuild>true</GeneratePackageOnBuild>
  </PropertyGroup>

  <PropertyGroup>
    <Version>1.0.11</Version>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="ProjectA" Version="[1,2)" />
     ...
  </ItemGroup>

  <ItemGroup>
    <ProjectReference Include="..\ProjectA\ProjectA.csproj" />
  </ItemGroup>
  
</Project>

3. Build packages.

Actual behavior:

Build generates .nupkg with correct .nuspec

but dependencies node shows warning on NuGet

Expected behavior:

No warning shown on NuGet dependency.

[Pilchie]

Why do you want to have both a package reference and a project reference to the same things?

[YakhontovYaroslav]

Since SDK based csproj supports setting all .nupkg related stuff inline, we decided to drop .nuspec file dependency during build\pack. This approach (setting Package and Project reference to the same thing)
allows us to not wait for CI build if some one changes both parent (project A, in case project B referencing project A) and project B code, due to fact they are tied as ProjectReferences in same solution. Setting PackageReference in form of
<PackageReference Include="A" Version="[1,2)" />
sets correct version constrains in generated package B nupkg during pack. See in screenshots above R1.Common.DataAccess.Interfaces dependency, that`s our project A is this case. MsBuild analized Version="[1,2)" constraint, and resulted NuGet package of project B contains R1.Common.DataAccess.Interfaces >= 1.2.6 && < 2.0.0 constraint, where 1.2.6 is a current version of this package during build.

So basically this changes workflow from this when working within one sln (classic csproj + .nuspec):

1. Change code in project A and update version in .nuspec
2. Push changes
3. Wait for CI to build and push updated package A
4. Update package reference A in project B, change code in project B and update version
5. Push changes
6. Wait for CI to push updated package B

to this (SDK based csproj, no .nuspec files):

1. Change code in project A, update version in csproj
2. Change code in project B, update version in csproj
3. Push changes
4. CI will build and push both A and B with correct versions constraints in one cycle.

Greater alternative would be allowing setting NuGet version constraints right in ProjectReference node, like this:
<ProjectReference Include="..\ProjectA\ProjectA.csproj" NuGetVersionConstraint="[1,2)" />

[Pilchie]

Got it, thanks @YakhontovYaroslav. That's what I suspected, but wanted to confirm.

@emgarten @rrelyea - what do you expect to happen in cases like this?

[emgarten]

The restore behavior is correct, you cannot have both a package and project reference.

I suggest using a condition and passing an additional property when calling pack to switch over to the view you want pack to see.

The root issue here seems to be that pack doesn't support custom version ranges for project references, that is tracked here: NuGet/Home#5556

[YakhontovYaroslav]

@emgarten Issue You have referenced will indeed provide descent solution, once implemented, in fact i have suggested similar alternative above.

But im not sure about first part of Your answer. You mentioned that i cannot have both type of references to the same thing, while sure i can. Restore\Build\Pack\etc works flawlessly both in VS, CLI (msbuild) and CI with such approaches. Im not sure what MsBuild does in this case under the hood, but im suspecting it just ignores PackageReference, relying solely on ProjectReference. The only quirk is dependencies node in VS UI. Its not that much of an issue, but its really confusing when i`m trying to figure out whether there are real issues with project dependencies or not.

Conditional references will sure fix the problem, but imho its just too heavy to embrace and follow for regular developer. In fact Setting PackageReference Version constraints already forces us to edit csproj manually (adding\updating references through NuGet UI will remove any Version constrains that was set earlier). Ideally VS should allow user to set Project and Package references version constraints through Properties window and Add Reference\NuGet package dialogs.

[tmeschter]

@drewnoakes Take a look and see if this scenario has any weird behavior in the current implementation of the Dependencies tree.

[drewnoakes]

The dependencies tree is working correctly here. There is no resolved package in this case, so it appears with a triangle.

I sympathise with the request to make it easier to substitute a project reference in the IDE with a package reference during pack. It seems like @emgarten's approach is the way to go.