Nuget Restore Circular Dependency

[brthor]

I've run into an issue where having a directory containing a project.json and named the same as one of the dependencies causes a Circular Dependency.

To repro create a directory structure like so:

System.Console (directory)
-> project.json

Then put System.Console as a dependency in the project.json:

{
    "dependencies": {
        "System.Console": "4.0.0-beta-23225"
    },
    "frameworks": {
        "dnxcore50" : {}    
    },
    "runtimes": {
        "win7" : {}
    }
}

Running "nuget.exe restore ./project.json" on this will cause the following error:

Cycle detected:
    System.Console (≥ 1.0.0) -> System.Console (≥ 4.0.0-beta-23225) -> System.Console (≥ 4.0.0-beta-23225).
Cycle detected:
    System.Console (≥ 1.0.0) -> System.Console (≥ 4.0.0-beta-23225) -> System.Console (≥ 4.0.0-beta-23225).

This behavior is perplexing, and the cause is very difficult to track down from the error message. Is there a reason this behavior exists or is it a bug?

I'm using nuget.exe 3.2.0.10516

[yishaigalatzer]

The though here is that project names and packages name are interchangeable. So Project to Project references are treated the same as package dependencies.

This is not yet a common pattern in nuget, and more so in DNX. But this is the path going forward

[brthor]

Project to Project references make sense when you are referencing a different project. That behavior is pretty useful.

A project should never reference itself though, so my thought is why does the current project satisfy the dependency?

[davidfowl]

These are plans to let you specify the ID of the package in project.json but the behavior would be the same in either case. The project itself is part of your dependency graph.

[brthor]

I appreciate the quick responses! I am working through this issue currently.

Specifying the ID of the package would be very useful as a workaround to this issue. Is this implemented or still planned?

In what situation though should the project currently being restored be used to satisfy a dependency? I don't think I understand the whole picture here.

I think the core of my question is why is the current project a part of the dependency graph?

[davidfowl]

Because projects and packages are going to be interchangeable in this new world. The entire idea is that nuget is fully integrated into the workflow (not an addon). With project.json NuGet understands the full P2P graph as well as the package dependencies that go into it. If you're using project.json with a csproj, it's conceivable that we can name things based on the csproj instead of the folder, xproj has this current limitation however

[mcse3010]

I'm with @brthor on this one -- the current project should never be part of a dependency graph for the project you are building -- E.g. in this case, if you're building "Foo" and you have "Foo" in your project.json, the default behavior should be to ignore the project references (where projectname being built == reference name) and go straight to package resolution... In other words it should be a special case that excludes the current project from the list of potential project references

[brthor]

@davidfowl Even though projects and packages are interchangeable, adding the current project to the dependency graph only seems to enable the scenario where a project references itself. The only other scenario I can think of is when Project A references Project B which references Project A, but this is a circular dependency and isn't supported anyways.

@mcse3010 This is exactly along the lines I am thinking.

Are there scenarios that break from introducing the special case as @mcse3010 detailed?

[yishaigalatzer]

I still don't get why we should add it with any urgency and why would you name your project system.console?

Special cases add complexity and we should be very careful with them. We do want to detect and for id circular dependencies which is what this code does.

[brthor]

System.Console was purely an example. I could see this being an issue for any package authors who unwittingly create directory structures with the names of their package(s).

In my particular case, we had a large number of directory structures created in such a way to trigger this behavior. It took quite some time to figure out what was happening.

The most perplexing part is that it seems to pick the current project over the package even though the current project does not meet the version requirements.

I can see how this is important for identifying circular dependencies though. Removing the current project from the graph entirely would break circular dependency detection, but simply ignoring the current project as a potential project reference should not.

[yishaigalatzer]

Package authors would/should never name another one of their projects as the package name. This will be the package project itself.

Not against fixing it, it is just very low priority.

---

From: Bryan Thornburymailto:notifications@github.com
Sent: ‎9/‎22/‎2015 2:38 PM
To: NuGet/Homemailto:Home@noreply.github.com
Cc: Yishai Galatzermailto:yigalatz@microsoft.com
Subject: Re: [Home] Nuget Restore Circular Dependency (#1428)

System.Console was purely an example. I could see this being an issue for any package authors who unwittingly create directory structures with the names of their package(s).

In my particular case, we had a large number of directory structures created in such a way to trigger this behavior. It took quite some time to figure out what was happening.

The most perplexing part is that it seems to pick the current project over the package even though the current project does not meet the version requirements.

I can see how this is important for identifying circular dependencies though. Removing the current project from the graph entirely would break circular dependency detection, but simply ignoring the current project as a potential project reference should not.

—
Reply to this email directly or view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fNuGet%2fHome%2fissues%2f1428%23issuecomment-142430124&data=01%7c01%7cyigalatz%40microsoft.com%7c6522ee5f8385466f98a008d2c39626c1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=NuKLAguLu6As30MO9peYiJmyBpuAUyQueHadduqxsqY%3d.

[mcse3010]

I certainly did not mean to imply any urgency -- it is definitely an edge
case -- a fairly obscure one at that, which has a known workaround...

[brthor]

Fair enough. Only a small number of people should hit this and the workaround is as simple as renaming your parent directory, so I agree this is not particularly urgent.

[chrsin]

I am experiencing this problem with a directory structure like this (In a dotnet core project)

/src/Company.Project/project.json
/test/Company.Project.Test/project.json (Experiencing the problem in this project)

If i rename
"/test/Company.Project.Test/project.json"
to
"/test/Test.Company.Project/project.json"
I don't get the error anymore. Is this as expected?

[YetaWF]

Some of my solutions consist of a lot of projects (500+, many of which are non open source), and include 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 updated 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.

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 (notice "nuget:"):

  "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". True. 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.

Thank you for letting me vent.

[nkolev92]

Package-Project duality is where NuGet has migrated since the packages.config world.
Package Reference has the same "issue". This is not a practice we want to encourage, because this would not work if someone tries to pack the said project.

Closing this as won't fix.

[philcarbone]

We are running into this. We've had many packages created the same way (for months) and all of a sudden our latest package is complaining about this issue, stating that it is referencing itself. It seems like this is an issue that shouldn't go unresolved. In our case, it has a nasty cascading effect on all of our users and documentation. You claim that it will only affect a "small number of people" - the issue is bigger than the number of packages it affects. It is the cascading issue that is the problem. I don't think moving forward with such a design flaw is a wise move. What can be done to correct this? BTW - we used built in project templates to create our projects in our solution and then used the built-in packaging options in the project (.NET Standard) to create this package. This shouldn't just be broken out of the box like this!

[philcarbone]

@nkolev92 Don't you think it is extreme to just close this as "won't fix" (you are committing to NEVER fixing a problem that you may not know how much impact it really has). It would be better to just leave it open and say it currently isn't a priority. Instead you are saying you choose to leave the flaw, because that's how you roll (that leaves a bad taste in the mouth). Who else can we include in this conversation to really discuss the direction that these packages are going?

To be clear: this issue is showing up in situations that it shouldn't (e.g. We have project folder names that just CONTAIN the name of the package, and that's an issue too).

Isn't Microsoft developing out in the open now? I fail to see how this was any kind of collaboration.

I think there are pockets like this, where the developers are being mistreated and overlooked (which gives Microsoft a bad name), while other projects by Microsoft are being very collaborative and cooperative with the community.

Your built-in tooling creates the issue for people (out of the box). That should be addressed.

[philcarbone]

https://yetawf.com/BlogEntry/Title/Project%20Names%20and%20NuGet%20Package%20Names/?BlogEntry=1007

Quote from this URL:

It seems, once again, smart people developing code/tools without real world experience

[philcarbone]

One last thing to vent on (I promise) - I sent an email to 'support@nuget.org' We described our issue in detail and provided the xml for the project file and have had ZERO response. Yet, this email is posted on the nuget.org site for people to request support.