使用本地项目引用覆盖 nuget 包引用

Question

I'd like iterate on a nuget package without continuously pushing the package to a nuget feed.

I'm wondering if it's possible to conditionally add a project reference instead of a nuget package reference via a target or props file in csproj files that would allow me to locally debug my nuget package.

In my csproj I would have:

<Reference Include="A">
    if(Exists(localOverrides.props) {
        <HintPath>localOverrides.A.HintPath</HintPath>
    } else {
        <HintPath>..\packages\A.dll</HintPath>
    }
</Reference>

and localOverrides.props would be a file listed in my .gitignore that developers could add lines to like:

A -> C:\Repos\A\bin\A.dll

Am I on the wrong path? Surely there must be a more sustainable way to quickly iterate and debug a nuget package then creating pre-release packages on every change

Answer 1

The way I have always debugged Nuget package is once you have that package added to your solution through Nuget, you then make changes to the Nuget DLLs and just copy them into the correct folder in the packages folder for the project consuming the Nuget package.

All you have to do is compile the solution that Nuget project solution in debug mode and just copy/paste them into the consuming project's packages folder. You could make this even simpler by writing a batch script and adding it as a post build event to the Nuget project that just copied the DLLs into the correct folder for you.

Answer 2

If all you want to acomplish is to debug the NuGet package I suggest you use "dotpeek debug server" option. This way you don't need to do anything with the reference and simply debug the package or whatever you want. https://confluence.jetbrains.com/plugins/servlet/mobile#content/view/53336814

Answer 3

Sounds like you want a test project (unit or integration) in the same solution as your NuGet packaged assembly project. Then you can prove it's correctness independently of any consumers of the NuGet package. Good tests will also help ensure you don't break anything unintentionally when updating the package in the future.

Answer 4

There is a much easier way, in which you could use both: project references during development (faster), and package references during production.

In your .csproj project file:

<ItemGroup Condition="'$(Configuration)'=='Debug'">
  <ProjectReference Include="../../../Library1/Library1.csproj" />
  <ProjectReference Include="../../../Library2/Library2.csproj" />
</ItemGroup>
<ItemGroup Condition="'$(Configuration)'!='Debug'">
  <PackageReference Include="Library1" Version="1.0.0" />
  <PackageReference Include="Library2" Version="1.0.0" />
</ItemGroup>

In development : project compiled in debug mode, so the project reference will be used.

In production (CI server, docker container): project compiled in release mode, so the package reference will be used.