Ufdjrw

So I have Project B referencing on Project A. Both are .net standard libraries. I want to create a nuget package using VS 2017.
I simply filled Properties->Package settings by checking "Generate Nuget Package on build" on Project A.

I even added for Project B

 <PropertyGroup>
 <TargetFramework>netstandard2.0</TargetFramework>
 <IsPackable>false</IsPackable>
 </PropertyGroup>

But once I build and nuget package for Project A is created. It displays as Project B is another nuget package reference. if i unzip the nupkg file, in the nuspec, I can see following lines

 <dependencies>
 <group targetFramework=".NETStandard2.0">
 <dependency id="ProjectB" version="1.0.0" exclude="Build,Analyzers" />
 <dependency id="NETStandard.Library" version="2.0.3" exclude="Build,Analyzers" /> 
 </group>
 </dependencies>

you can see that projectB is taken as nuget package reference. On install it fails also saying "cannot find ProjectB nuget"
Why is this happening? is it a bug in VS 2017?
I even added below settings in ProjectA that it should include ProjectB as dll which works fine. But despite that it also register as nuget dependency

<Target Name="IncludeP2PAssets">
 <ItemGroup>
 <BuildOutputInPackage Include="..ProjectBbinReleasenetstandard2.0ProjectB.dll" />
 </ItemGroup>
 </Target>

my project A csproj file doesnt have any packagereference as Project B, as below it is set as Projectreference

 <ItemGroup>
 <ProjectReference Include="..ProjectBProjectB.csproj" />
 </ItemGroup>

 <ItemGroup>
 <PackageReference Include="NETStandard.Library" Version="2.0.3" />
 </ItemGroup>

When packing a project, project to project references are considered by default as nuget package references. I can think of two reasons why this is a good thing.

1. it's recommended to pack one assembly per package


2. to simplify development experience for package authors

Let's consider these two reasons

1. it's recommended to pack one assembly per package

Imagine there's some utility assembly utility.dll and I use it in my package, PackageA. If I put both PackageA.dll and utlity.dll in my package, but later create a PackageB which also contains utility.dll, then there will be conflicts if a single project uses both PackageA and PackageB because there will be two different utility.dlls. By having one assembly per package, there would be a PackageA and PackageB, both of which depend on different versions of the utility package, and NuGet can use it's versioning rules to pick one.

2. to simplify development experience for package authors

Imagine I have PackageB which depends on PackageA, and I want to make a change that requires changes to both PackageA and PackageB. If PackageB has a PackageReference to PackageA, that means I have to guess what changes I'm going to need in PackageA to finish the changes in PackageB, change, commit, pack and publish PackageA, then change PackageB to use the new version of PackageA. However, if my guess about the needed changes in PackageA were wrong, then I'll need to again change, commit, pack, publish PackageA and then change PackageB to use the new, new version. It's slow and painful to make a multi-package feature when using package references.

However, by making PackageA a project reference from PackageB, I can modify PackageA and the changes are immediately available in PackageB without having to create multiple versions of PackageA.nupkg.