Reputation: 7414
I have three projects I'm building
The FooBar.AspNetCore
and the FooBar.AspNetCore.IntegrationTesting
projects both have references to FooBar.Abstractions
. I want to package and ship all three of these as individual NuGet packages.
I started with a NuGet.config
file that looks like this locally:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="aspnetcore_abstractions" value="./src/FooBar.Abstractions/bin/Debug/" />
</packageSources>
</configuration>
Then I add the package to my projects
<ItemGroup>
<PackageReference Include="FooBar.Abstractions" Version="2.0.0-preview1" />
<PackageReference Include="Microsoft.AspNetCore.Http.Abstractions" Version="2.2.0" />
</ItemGroup>
This really sucks though as each time I make a change in the FooBar.Abstractions
project I have to go into my C:\.nuget\packages folder and delete the cache before my FooBar.AspNetCore
project can restore the newly compiled version from my solution.
If I just add FooBar.Abstractions
as a project reference, and then I ship the two packages to NuGet.org, how does that affect users that install the two packages across different projects in their solutions. Does NuGet and .Net figure it all out, knowing that they're the same referenced assembly? I assume in this case the FooBar.AspNetCore
project will ship with the FooBar.Abstractions.dll
in it if I add it as a project reference.
I don't know if that causes conflicts knowing that the package ships that .dll, then a customer installs the Abstractions package explicitly that contains the same .dll.
How do you handle this with NuGet packaging with the newest versions of NuGet? How do I constrain FooBar.AspNetCore
to use the same FooBar.Abstractions.dll
version between the package reference and the NuGet package others will install? I can't force PackageReference Include="FooBar.Abstractions" Version="2.2"
if I'm adding it as a project reference instead can I?
Upvotes: 0
Views: 136
Reputation: 14961
When you pack a project with at project reference, NuGet converts the project reference into a NuGet dependency. It figures out the dependency version based on what version that project would be if it were packed. There is no need to use PackageReference
when packing. As you discovered/explained, doing so makes local development much more difficult.
Therefore the solution to your problem is to just use ProjectReference
when the projects are in the same source code repository.
Upvotes: 1