.NET Core RC2: use local fork of a package

Question

I have a project which in turn references a fork of an official nuget'd library (forecast.io). I've arranged my global.json to find my copy of the lib, yet a dotnet restore still seems to reach out to the official version rather than my fork.

I form this conclusion because I get the error:

Package Forecast.io 1.0.0 is not compatible with netcoreapp1.0 (.NETCoreApp,Version=v1.0). Package Forecast.io 1.0.0 supports: net45 (.NETFramework,Version=v4.5)
One or more packages are incompatible with .NETCoreApp,Version=v1.0.

Yet my fork of forecast.io doesn't even target .NET 4.5 - only "net40" and "netcoreapp1.0".

How can I ensure that my local fork is used instead?

Here's my global.json

{
  "projects": [
    "../../ext/forecast.io-csharp/src/Forecast.io",
    "MyOtherLibRefWhichWorks",
    "MyPrimaryProject"
  ]
}

And a snippet from project.json from primary project:

  "dependencies": {
    "Microsoft.NETCore.App": {
      "type": "platform",
      "version": "1.0.0-rc2-3002702"
    },
    "MyOtherLibRefWhichWorks": "1.0.0-*",
    "Forecast.io": "1.0.0-*",

EDIT: It seems like global.json goes completely ignored. It's located one directory above where the project.json is located..

Doing this results in 'Unable to resolve 'Forecast.io'' (I applied change to project.json) - seems like a potential step forward presuming global.json is somehow being ignored — Malachi, Jun 20 '16 at 22:40
What happens when you add the current project to global.json too? — svick, Jun 20 '16 at 22:43
It appears to have no affect. Am I making a dumb mistake and accidentally disabling global.json? I've edited the original post to reflect global.json changes — Malachi, Jun 20 '16 at 23:25

Nate Barbettini · Accepted Answer · 2016-06-20T23:31:29.673

2

Creating your own local or remote Nuget feed will be a much more reliable solution for this situation. I do this myself for managing beta versions of packages I publish and it works really well.

To do it locally, you just need an empty folder and the Nuget CLI. If your folder is C:\Nuget, run

nuget add package.nupkg -source C:\Nuget

To add your forked package to the local feed. To make sure there isn't any confusion, build your forked package with either a different name or version number than the official package.

Then, configure Nuget to use your local feed as a source:

nuget sources Add -Name LocalNuget -Source C:\Nuget

Once this is all set up, update your project.json to reference your forked package and run dotnet restore again to pull down the local copy.

If you need to restore the package on multiple machines, or in a team environment, you can set up your own NuGet server or use MyGet.org to host your package.

edited Jun 20 '16 at 23:31

answered Jun 18 '16 at 04:12

Nate Barbettini

51,256
26
134
147

This is works well, almost exactly as stated (nuget add didn't exist for me, so I merely copied the nupkg manually) . However, I'm concerned about a) the inevitable version-name churn in project.json and b) the per-machine setup required - albeit not tremendous – Malachi Jun 20 '16 at 23:17
You can download `nuget.exe` from the above link and place it in your PATH if you want to use the CLI. You're right, this doesn't work well for a team unless you put the package in a shared network location. A better solution in that case would be MyGet! – Nate Barbettini Jun 20 '16 at 23:20
@Malachi What do you mean by "the inevitable version-name churn"? – Nate Barbettini Jun 20 '16 at 23:20
For the record, I'm doing dev on many different platforms. I'll check out MyGet. and the version-name churn is gonna be when I (hopefully) pull request my change gonna have to revert/back out the forecastio-specialversion -- and if I update mine from upstream, I'll have to re-apply forecastio-specialversion.. – Malachi Jun 20 '16 at 23:28
@Malachi Ah, gotcha. Yeah, that's annoying, but I still think packaging it up as your own Nuget package is better than any other method of doing this. It's the most reliable way to restore exactly what you need in VS. – Nate Barbettini Jun 20 '16 at 23:30
I'm hoping for a more "inline" solution like a functioning-as-expected global.json. In the meantime I've been using symlinks... which get me the result but maybe a bit too hack-ish... that said, your suggestion seems to align with best practices – Malachi Jun 20 '16 at 23:34
Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/115156/discussion-between-malachi-and-nate-barbettini). – Malachi Jun 20 '16 at 23:37
1

Using your solution. I'm also including NuGet.Config in the folder near global.json to auto-config the myget.org feed, since nuget/dotnet restore auto-discovers it (convenient!) – Malachi Jun 21 '16 at 18:53

.NET Core RC2: use local fork of a package

1 Answers1