CODEWITHSUNDEEP
nuget
Machinarius
Machinarius

Reputation: 3731

How to switch between nuget and project references effectively?

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.

Upvotes: 13

Views: 6720

Answers (4)

Anoni2
Anoni2

Reputation: 81

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>

  1. 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.

Upvotes: 0

Jeremy Thompson
Jeremy Thompson

Reputation: 65682

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

enter image description here

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.

Upvotes: 1

Sam Peacey
Sam Peacey

Reputation: 6034

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

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

Upvotes: 11

raV720
raV720

Reputation: 606

  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>
  1. Use appropriate configuration for debugging with project reference and releasing with nuget reference

Upvotes: 6

Related Questions