How to temporarily replace a NuGet reference with a local build

Question

I'm working on a C# project using Visual Studio 2015, with NuGet for package management. For one reference, I'd like to temporarily use a local build while I'm iterating on a fix, rather than the released version. What's the best way to accomplish this?

If I were using an SVN external, I'd drop the new locally built copies into the external reference's folder, and be set. Other package management software (like CocoaPods) would allow me to point to a local directory to resolve the reference. With NuGet, it doesn't look like there's any mechanism for this.

When I try dropping my new DLL over the package reference inside the packages folder, I get inconsistent behavior in Visual Studio. My build will fail with hundreds of errors, most of which go away from the Error List quickly. I'm ultimately left with a warning telling me it could not resolve the reference to the assembly I'm trying to replace (though the properties of the reference do indicate it's finding my new version).

I'm trying to test out unfinished library code in my app that consumes it. Since it's unfinished, I'm not yet ready to commit and publish my changes. — Dov, Sep 09 '15 at 14:51
You know, that following SemVer and having a local repository does partially solve your problem ... What's the problem with committing beta-packages? Though, I do understand the additional overhead (which I am facing as well ...) — , Sep 09 '15 at 14:52
It's a matter of overhead, as you mentioned, and it seems like I should be able to test the code easily on my own machine before involving any repos. — Dov, Sep 09 '15 at 14:57
This is the main reason I prefer submodules over Nuget packages for internal libraries. https://stackoverflow.com/a/65817315/732673 — Josh Noe, Feb 10 '23 at 18:54

score 28 · Answer 1 · edited Sep 15 '21 at 08:10

28

I found the following workaround useful for me:

First I disable "NuGet Package Restore" from the context menu of the Solution.

After that I go to the %HOMEPATH%\.nuget\packages folder, and search for the package I want to replace. From this package I take the version number, and use this exact version number to build the dll I want to exchange.

After that I can exchange the dll in the packages folder with this newly built dll. Building the project now uses this new dll.

After having this set up once, I can easily build new dlls, and copy them to the packages folder.

edited Sep 15 '21 at 08:10

Leif Jones

320
6
21

answered Feb 03 '16 at 17:26

Matthias

817
2
7
14

6

disable "NuGet Package Restore" is not necessary – Michael Freidgeim Jul 03 '16 at 05:28
I get an error when I try this - "Assembly {assembly path} must be strong signed in order to be marked as a prerequisite." – Panayot Todorov Jan 19 '18 at 11:47
could you elaborate on how you "use this exact version number to build the dll I want to exchange." – Prashanth Subramanian Mar 10 '21 at 06:43

score 13 · Accepted Answer · answered Sep 09 '15 at 14:56

13

You can create your own Nuget feed (simple local folder + some configurations)

Read more here Hosting Your Own NuGet Feeds

answered Sep 09 '15 at 14:56

Alex F

3,180
2
28
40

4

Is there a way to switch to the local-folder package source other than uninstalling from the old one and then reinstalling? That's not so straightforward, as in the solution I'm working on there are 20 projects, only 5 of which use the library. It's not insurmountable, but annoying. – Dov Sep 09 '15 at 19:10
4

Did you ever find a good solution to this? Our team is working on multiple projects, and have a build pipeline in Azure DevOps. It'd be great to locally develop and consume those libs, and then have the DevOps build agent consume a build artifact from our Nuget feed. – Colin Jul 13 '19 at 02:06

Francisco d'Anconia · Answer 3 · 2020-01-27T22:59:21.993

10

We've had great success using this tool. It's easy to use and works.

VS 2019 https://marketplace.visualstudio.com/items?itemName=RicoSuter.NuGetReferenceSwitcherforVisualStudio2019

VS 2017 https://marketplace.visualstudio.com/items?itemName=RicoSuter.NuGetReferenceSwitcherforVisualStudio2017

VS 2015 https://marketplace.visualstudio.com/items?itemName=RicoSuter.NuGetReferenceSwitcherforVisualStudio2015

edited Jan 27 '20 at 22:59

answered Jul 05 '17 at 16:36

Francisco d'Anconia

2,436
1
19
25

2

Unfortunately this no longer seems to support newer project files. – AJ Henderson Aug 12 '19 at 12:26
1

I added the VS 2019 link. It may help @AJHenderson (not tested). – Kit Jan 24 '20 at 20:57
1

@Kit: it seems not, unfortunately. With VS 2019 and the provided extension version, I get an error popup with a stack trace and hint to unload projects with new `.csproj` format. – miniyou Mar 12 '20 at 09:56

C Rudolph · Answer 4 · 2021-02-01T17:34:46.740

In VS2019, this is how you can conditionally switch on build between project reference and package reference. We use this for our docker containers

Open your project solution "Solutions\Bookstore\Bookstore.sln" that has the project "Bookstore.csproj" that will reference the nuget
Add a solution folder for example "nuget" and add existing project "Solutions\Library\library.csproj"

Add conditional item group to the project file "Bookstore.csproj"

<ItemGroup Condition="Exists('..\..\Library\library.csproj')">
  <ProjectReference Include="..\..\Library\library.csproj" />
</ItemGroup>
<ItemGroup Condition="!Exists('..\..\Library\library.csproj')">
  <PackageReference Include="library" Version="1.0.0" />
</ItemGroup>

In solution explorer, right click Bookstore solution > properties > configuration properties. For the configuration 'Release' uncheck the project 'library.csproj'. Now when your code is built in debug, it will build the project reference. When it is built in release it won't try to build it.
When we publish make sure you use 'Release'. This works because when you publish it will not be able to find "Solutions\Library\library.csproj" from the path we configured in Bookstore.csproj "..\..\Library\library.csproj".

You don't have to use docker for this to work but as an example here is the commands our dockerfile will run

WORKDIR "/Solutions/Bookstore"
RUN dotnet restore
RUN dotnet build -c Release -o /app
FROM build AS publish
RUN dotnet publish "Bookstore.csproj" -c Release -o /app
FROM base AS final
WORKDIR /app
COPY --from=publish /app .

score 6 · Answer 5 · answered Feb 28 '21 at 00:42

6

DNT (DotNetTools) is pretty up to date and has commands to switch from packages to local project references and back again.

dnt switch-to-projects

dnt switch to packages

https://github.com/RicoSuter/DNT#switch-to-projects

answered Feb 28 '21 at 00:42

Kevin Somers-Higgins

957
1
10
12

score 3 · Answer 6 · answered Jul 15 '22 at 03:54

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

How to temporarily replace a NuGet reference with a local build

6 Answers6