Johnathon Sullinger
Johnathon Sullinger

Reputation: 7414

Shipping projects as NuGet packages while depending on each other

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

Answers (1)

zivkan
zivkan

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

Related Questions