This is no longer applicable as Visual Studio returned to using *.csproj files and project.json is no longer used.

The YetaWF solution consists of a lot of projects (500+, many of which are non open source), and includes a fair number of third-party components. While converting to MVC6, I experienced an odd error message:

Cycle detected:
    YetaWF2 (>= 1.0.0) -> Twilio  -> Twilio (>= 4.7.2) -> Twilio (>= 4.7.2).

This happened while converting our Softelvdm.Twilio package to MVC6. It's a YetaWF package that implements sending SMS (text messages) using Twilio's service. The project is aptly named Twilio in our solution. It has been named that for a long time (in Visual Studio 2013, 2015, 2017) while using MVC5. The NuGet package is also named Twilio.

So now with the great and improved ASP.NET Core MVC and the not so great Visual Studio tooling, NuGet packages used in any solution pollute the solution's project name space. So when I reference the Twilio NuGet package it was in conflict with my own project named Twilio.

Some comments here: https://github.com/NuGet/Home/issues/1428

It seems, once again, smart people developing code/tools without real world experience... The decision to elevate referenced packages to "solution projects" (or make all projects NuGet packages) in the same namespace, has a direct impact on non-trivial solutions and is an unnecessary complication.

Given that there is no way to specify the source of the package (Nuget vs. Solution) in project.json, I have to assume this ship has sailed and we chalk this up to another unfortunate decision made in designing the new and improved way of doing things.

Wouldn't life be sweet if I could do this to disambiguate the reference:

  "dependencies": {
    "nuget:Twilio": "4.7.2"
  },

Renaming my project is not sufficient as I then get this:

Errors in C:\Development\YetaWF2\src\Modules\Softelvdm\Twilio\Twilio2.xproj
Cycle detected:
     Twilio2 (>= 1.0.0) -> Twilio (>= 4.7.2) -> Twilio (>= 4.7.2) -> Twilio (>= 4.7.2).

I also have to rename the folder to the new name.

Someone suggested this will only hit a "small number of people". But, for the chosen few, it may cause a significant amount of work. Changing a project and folder name in my case forces updates in customer facing documentation, recreating old (MVC5) packages to match, and probably the occasional phone call explaining that the project name and folders have changed.