How to switch between nuget and project references effectively?

Question

I am developing a private test harness that is split between a core library with a couple of extension plugins.

The extension projects depend on a core library via a private MyGet feed so i can just click pack and upload to the MyGet feed without much hassle. The issue i'm having is that any API update to the core lib isn't reflected on the extension libs unless i issue a completely new version of the core NuGet package.

That in itself isn't so bad but it has two productivity-killer implications: I can't debug core code in an extension code context and making my development iteration process dependant on MyGet is a huge slowdown.

How can i fix this? I've been manually switching between project and NuGet dependencies every time i want to generate new NuGet packages but i'm pretty sure someone else must have a better solution to this problem.

Sessile

you may want to follow github.com/dotnet/sdk/issues/1151 – Brickwork

Answer 1

I've been using NuGet Reference Switcher to do this - it's a Visual Studio extension to handle exactly this problem:

• VS2015: https://marketplace.visualstudio.com/items?itemName=RicoSuter.NuGetReferenceSwitcherforVisualStudio2015
• VS2017: https://marketplace.visualstudio.com/items?itemName=RicoSuter.NuGetReferenceSwitcherforVisualStudio2017

The workflow using this is still not perfect, but it's better than manually switching projects. I'd love to hear other ideas though.

Treasurer

I ended up using conditional references based on whether the referenced project was reachable or not, using the package reference in the latter case. This suited my need to package my app on docker containers effectively – Sessile

@Machinarus can you provide an example of that? – Mediate

Note: Someone else even modified the reference switcher to VS2022. github.com/Schnazey/NuGetReferenceSwitcher – Photochronograph

Answer 2

1. Add library via nuget
2. Add the same library via project reference
3. Edit project file and add conditions:

<ItemGroup>
<PackageReference Include="Library.Common" Version="3.0.1" Condition="'$(Configuration)'=='Release'"/>  
</ItemGroup>

<ItemGroup>
<ProjectReference Include="..\..\Library.Common\Library.Common\Library.Common.csproj" Condition="'$(Configuration)'=='Debug'"/>
</ItemGroup>

4. Use appropriate configuration for debugging with project reference and releasing with nuget reference

Forging

I had a lot of problems with this, there's some glitch in VS2022 when you switch between Debug to Release (and you're using a type of NuGet repo) it doesn't do the switch and results in compile errors. The NuGet Switcher gets my vote. – Beatrisbeatrisa

Pure csproj hacks get my vote. Introducing some non-Microsoft supported build tool is asking for trouble. Sure you don't want all your packages to get deleted? Microsoft, please add native support for this! – Erich

This idea looks nice, but is horrible once implemented: Usually you would use nuget package for external repositories (otherwise you would have used the project reference anyway ;) ). With this way you are required to have your projects within your .sln file configuration. As soon as you haven't checked out your external repo, your solution won't build (on CI). You need to create another build config in your solution, disable all projects to replace for each build config and keep a <configuration> entry in each .csproj of your solution, that mentions this new debug-configuration as well. – Photochronograph

Answer 3

So fed up with the situation I decided to make a tool to do it, sponsor me GitHub star if you like it: https://github.com/MeaningOfLights/NugetDebugSwitcher

Say you have a Solution with ProjectA that references a Library.Base DLL. In the ProjectA.csproj file we can see the reference:

<PackageReference Include="Library.Base" Version="2.1.0" />

What this tool will do is backup the Nuget Library.Base Package Lib folder. Then it creates a SymLink so the Nuget Library.Base Package Lib folder is a shortcut to the Project Reference Debug folder.

After simple clean of the solution you can then debug into the Library.Base. Hey presto!

Click the Remove Symlinks button to restore the backups and use the real NuGet DLLs. Code contributions welcome!

It's based off a Command Line Utility NuLink.

Beatrisbeatrisa

Answer 4

Those package switcher add-ons did not work, and the previous top-solution forced to use the package upon debug and have the project always within the solution available. I would like to document my solution hereby:

1. Define a script that depends on a variable.

<PropertyGroup>
  <!-- Default: False. Switch requires execution of script -->
  <UseProject>true</UseProject>
</PropertyGroup>

<ItemGroup>
  <PackageReference Include="Library.Common" Version="3.0.1" Condition="'$(UseProject)'=='false'" />
</ItemGroup>

<ItemGroup>
  <ProjectReference Include="..\..\Library.Common\Library.Common\Library.Common.csproj" Condition="'$(UseProject)'=='true'" />
</ItemGroup>

2. Add two .ps1 scripts to add/remove your project dynamically.

   dotnet sln MySolution.sln add -s FromNugetPackage ....\Library.Common\Library.Common\Library.Common.csproj

   dotnet sln MySolution.sln add -s FromNugetPackage ....\Library.Common\Library.Common\Library.Common.csproj

To switch the packages, you still need to redefine the variable and run one of the two scipts, but I think that is the best solution yet. You can clearly optimize this, to switch the variable of course, but that's something I'll skip for now.

Photochronograph

I struggled with the markup. If one could improve this, that would be great, thanks. – Photochronograph