Is there a .NET (Core) equivalent of npm link?

Question

This essentially amounts to, "how do I clone a .NET project, make modifications, and use it rather than the published one?"

In NodeJS, we have npm link, which lets you link a local package (module) in your node_modules/ directory, to your current project. So for example, instead of using Express in your package.json, you can

1. Clone Express
2. Make modifications to express
3. Compile (transpile, if necessary) and/or build
4. Run npm link in Express repo to create a globally available local package
5. Run npm link express in your current project to use your local express, rather that the one you would get if you npm install it.

With .NET, the closest solution I have seen so far includes creating a local feed, but in my experimentation this doesn't seem to work. Other questions on stack overflow like how to use local packages in .net seem to offer solutions using RestoreSources, which is virtually undocumented across the entire web. When attempting to change RestoreSources to use a LocalPackages directory, it is not clear to me the local packages are being used or not (source in obj/ directory still seems to come from nuget package rather than local).

Visual

nuget add can be used to accomplish the same thing. What you'll do is create a local nuget and add the local version to your project. This link gives you a step-by-step: medium.com/@churi.vibhav/… – Marika

Answer 1

For anyone in the future wondering this, the correct answer is to use the local feed. My problem was that I had cached nuget packages which were being resolved during dotnet restore.

The following command before restore solved my issues:

dotnet nuget locals all --clear
dotnet restore

Essentially, you need to have a nuget config (NuGet.config) in your solution that sets up your local packages directory:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
    <clear />
    <add key="LocalDev" value="./my-project/artifacts" />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
</packageSources>
</configuration>

Where artifacts/ directory contains all of the .nupkg packages you want to use during restore. It is obviously also essential that you must make sure those packages are built/compiled before you dotnet restore in your primary solution:

dotnet pack /p:Version=5.22.12 --configuration Release --force --output "%~dp0artifacts";

Visual

I have found an alternative approach that possibly can provide a bit better experience (e.g. debug) and not require any configuration files: https://mcmap.net/q/1702685/-is-there-a-net-core-equivalent-of-npm-link – Hideous

I guess another option could be a reference to the compiled .dll file of the library (like https://mcmap.net/q/294109/-reference-external-dll-in-net-core-project). If you dotnet watch build the library then the .dll gets updated automatically. – Phyllisphylloclade

Answer 2

There is a project that tries to do npm link like experience that is called NuLink. It essentially creates symlinks from cached nuget package to your package bin/Debug folder. It will be a better experience that using local feed.

I am a bit cautious with installing 3d party .exe files, so I have used the simple version of the approach used in NuLink that does not require any 3d party tools:

1. Install an old version of your package (e.g. 1.0.0). You can just reference it in your consuming project and run dotnet restore e.g.
2. Rename/remove lib folder from the installed package. Windows example: rename C:\Users\<USERNAME>\.nuget\packages\MyPackage\1.0.0\lib lib_old
3. Create a symlink/junction from it to your package debug folder. On windows it will be something like this: mklink /J C:\Users\<USERNAME>\.nuget\packages\MyPackage\1.0.0\lib C:\Source\MyPackage\bin\Debug
4. "Downgrade" to version 1.0.0 of your package in you consuming project

Now your consuming project should be referencing the folder with your .dll/.pdb files from your package for as long as you use 1.0.0. You just build your package, then it should become available right away including navigating to files and debugging (since .pdb file is in the same folder).

P.S. There are probably a lot of tweaks depending on versions of dotnet/nuget you are using, but the gist should still be the same with some variations in folder structure.

Hideous