Common dnu restore issue: Unable to locate PROJECT_NAME.dll >= 1.0.0

[guardrex]

I commonly get exceptions reporting that the PROJECT_NAME.dll file cannot be found and must delete the contents of the bin folder to get dnu restore to work properly. Here is the end of output showing the exception.

Writing lock file C:\PATH\PROJECT_NAME\project.lock.json
Restore complete, 1131ms elapsed
Restoring packages for C:\PATH\PROJECT_NAME\bin\Debug\app\project.json
  CACHE https://www.nuget.org/api/v2/FindPackagesById()?Id='PROJECT_NAME'
  CACHE https://www.myget.org/F/aspnetvnext/api/v2/FindPackagesById()?Id='PROJECT_NAME'
  CACHE https://nuget.org/api/v2/FindPackagesById()?Id='PROJECT_NAME'
Unable to locate PROJECT_NAME>= 1.0.0
Writing lock file C:\PATH\PROJECT_NAME\bin\Debug\app\project.lock.json
Restore complete, 6ms elapsed
Restoring packages for C:\PATH\paccharter\bin\output\approot\packages\paccharter\1.0.0\app\project.json
  CACHE https://www.nuget.org/api/v2/FindPackagesById()?Id='PROJECT_NAME'
  CACHE https://www.myget.org/F/aspnetvnext/api/v2/FindPackagesById()?Id='PROJECT_NAME'
  CACHE https://nuget.org/api/v2/FindPackagesById()?Id='PROJECT_NAME'
Unable to locate PROJECT_NAME>= 1.0.0
Writing lock file C:\PATH\PROJECT_NAME\bin\output\approot\packages\PROJECT_NAME\1.0.0\app\project.lock.json
Restore complete, 5ms elapsed
Restoring packages for C:\PATH\PROJECT_NAME\bin\output\approot\packages\PROJECT_NAME\1.0.0\root\project.json
  CACHE https://www.nuget.org/api/v2/FindPackagesById()?Id='PROJECT_NAME'
  CACHE https://www.myget.org/F/aspnetvnext/api/v2/FindPackagesById()?Id='PROJECT_NAME'
  CACHE https://nuget.org/api/v2/FindPackagesById()?Id='PROJECT_NAME'
Unable to locate PROJECT_NAME>= 1.0.0
Writing lock file C:\PATH\PROJECT_NAME\bin\output\approot\packages\PROJECT_NAME\1.0.0\root\project.lock.json
Restore complete, 3ms elapsed
Total time 1434ms
Errors in C:\PATH\PROJECT_NAME\bin\Debug\app\project.json
    Unable to locate PROJECT_NAME>= 1.0.0
Errors in C:\PATH\PROJECT_NAME\bin\output\approot\packages\PROJECT_NAME\1.0.0\app\project.json
    Unable to locate PROJECT_NAME>= 1.0.0
Errors in C:\PATH\PROJECT_NAME\bin\output\approot\packages\PROJECT_NAME\1.0.0\root\project.json
    Unable to locate PROJECT_NAME>= 1.0.0

[guardrex]

This is still occurring for VS 2015 RC (of course, since that's just running the command lines behind the scenes) ...

Writing lock file C:\MY_PATH\project.lock.json
Restore complete, 6915ms elapsed
Restoring packages for C:\MY_PATH\bin\Debug\app\project.json
  GET https://www.nuget.org/api/v2/FindPackagesById()?Id='PROJECT_NAME'.
  GET https://www.myget.org/F/aspnetvnext/api/v2/FindPackagesById()?Id='PROJECT_NAME'.
  GET https://nuget.org/api/v2/FindPackagesById()?Id='PROJECT_NAME'.
  OK https://www.nuget.org/api/v2/FindPackagesById()?Id='PROJECT_NAME' 299ms
  OK https://nuget.org/api/v2/FindPackagesById()?Id='PROJECT_NAME' 456ms
  OK https://www.myget.org/F/aspnetvnext/api/v2/FindPackagesById()?Id='PROJECT_NAME' 522ms
Unable to locate PROJECT_NAME>= 1.0.0
Writing lock file C:\MY_PATH\bin\Debug\app\project.lock.json
Restore complete, 549ms elapsed
Restoring packages for C:\MY_PATH\bin\output\approot\packages\PROJECT_NAME\1.0.0\app\project.json
  CACHE https://www.nuget.org/api/v2/FindPackagesById()?Id='PROJECT_NAME'
  CACHE https://www.myget.org/F/aspnetvnext/api/v2/FindPackagesById()?Id='PROJECT_NAME'
  CACHE https://nuget.org/api/v2/FindPackagesById()?Id='PROJECT_NAME'
Unable to locate PROJECT_NAME>= 1.0.0
Writing lock file C:\MY_PATH\bin\output\approot\packages\PROJECT_NAME\1.0.0\app\project.lock.json
Restore complete, 25ms elapsed
Restoring packages for C:\MY_PATH\bin\output\approot\packages\PROJECT_NAME\1.0.0\root\project.json
  CACHE https://www.nuget.org/api/v2/FindPackagesById()?Id='PROJECT_NAME'
  CACHE https://www.myget.org/F/aspnetvnext/api/v2/FindPackagesById()?Id='PROJECT_NAME'
  CACHE https://nuget.org/api/v2/FindPackagesById()?Id='PROJECT_NAME'
Unable to locate PROJECT_NAME>= 1.0.0
Writing lock file C:\MY_PATH\bin\output\approot\packages\PROJECT_NAME\1.0.0\root\project.lock.json
Restore complete, 28ms elapsed
Restoring packages for C:\MY_PATH\bin\Release\app\project.json
  CACHE https://www.nuget.org/api/v2/FindPackagesById()?Id='PROJECT_NAME'
  CACHE https://www.myget.org/F/aspnetvnext/api/v2/FindPackagesById()?Id='PROJECT_NAME'
  CACHE https://nuget.org/api/v2/FindPackagesById()?Id='PROJECT_NAME'
Unable to locate PROJECT_NAME>= 1.0.0
Writing lock file C:\MY_PATH\bin\Release\app\project.lock.json
Restore complete, 24ms elapsed
Total time 7850ms
Errors in C:\MY_PATH\bin\Debug\app\project.json
    Unable to locate PROJECT_NAME>= 1.0.0
Errors in C:\MY_PATH\bin\output\approot\packages\PROJECT_NAME\1.0.0\app\project.json
    Unable to locate PROJECT_NAME>= 1.0.0
Errors in C:\MY_PATH\bin\output\approot\packages\PROJECT_NAME\1.0.0\root\project.json
    Unable to locate PROJECT_NAME>= 1.0.0
Errors in C:\MY_PATH\bin\Release\app\project.json
    Unable to locate PROJECT_NAME>= 1.0.0

[davidfowl]

This looks extremely specific to something bogus in your project. Can you create give us some reproducible steps in a new project?

[guardrex]

@davidfowl I think I see why dnu restore is choking. Is dnu publish [and probably VS build (debug and/or release)] supposed to be adding a dependency for the project name itself and adding a folder to the packages in the name of the application?

C:\PATH_TO_PROJECT\bin\output\approot\packages

I see this package folder in the name of my project name with a 1.0.0 folder inside.

That folder gets put there during a dnu publsh, and there are generated project.json and project.lock.json files with dependency entries in the Release folder (and Debug when I do a VS build) that I think are choking ...

I look inside one of the generated project.json files and I see ...

{
  "webroot": "wwwroot",
  "version": "1.0.0",
  "dependencies": {
    "paccharter": "1.0.0"
  },
  "commands": {
... continued ...

... so you see a dependency section there with the project name and version, and I think it can't restore that.

There is also a generated project.lock.json ...

{
  "locked": false,
  "version": -9997,
  "targets": {
    "DNXCore,Version=v5.0": {}
  },
  "libraries": {},
  "projectFileDependencyGroups": {
    "": [
      "paccharter >= 1.0.0"
    ],
    "DNXCore,Version=v5.0": []
  }
}

... with another reference to a dependency on the project name itself.

When I manually delete the packages folder in the name of the project, manually kill the dependency lines for the project in these dependency sections of these files, the dnu restore goes through normally.

So ... questions are ... is it supposed to be putting a package in there with the project name ... is it supposed to be generating these project-named dependencies in these project.json/project.lock.json files. If so, shouldn't dnu restore be ignoring any dependency that matches the name of the project?

[dazinator]

TLDR; If you have an "artfifacts" folder in the same folder you are doing a dnu restore from, then you may see this error. You'll have to move it.

Long winded:
Perhaps worth mentioning but you also hit this problem in the following circumstance:

Suppose your directory structure looks like this:

/Src/ProjectA/project.json
/Src/ProjectB/project.json
/Src/ProjectC/project.json
/Src/Solution.sln

Then suppose you cd into the Src directory and do a dnu restore - things work as expected.

Now suppose, you are using Visual Studio to build your solution.. and for each project, you tick the option to output arttifacts on build. It creates an artifacts folder at the same level as the solution file - i.e in the Src directory:

/Src/ProjectA/project.json
/Src/ProjectB/project.json
/Src/ProjectC/project.json
/Src/Solution.sln
/Src/artifacts/bin/ProjectA/Debug/project.json
/Src/artifacts/bin/ProjectB/Debug/project.json

I have noticed that in that artifacts folder, it's placing project.json files.

Now when you cd into the Src directory and do a dnu restore - this error occurs, because dnu is recursing through all sub directories, and encountering these project.json files in the artifacts folder - and this exception in thrown.

The two work-arounds for this problem, are either to create a script that calls dnu restore individually on each project (which is a pain to maintain as you have to remember to update it as you add new projects etc) or, to modify your .xproj files, to change the path of the artifacts folder, so that it doesn't get placed in same directory that you do a dnu restore in:

/Src/ProjectA/project.json
/Src/ProjectB/project.json
/Src/ProjectC/project.json
/Src/Solution.sln
/artifacts/bin/ProjectA/Debug/project.json
/artifacts/bin/ProjectB/Debug/project.json

[codematrix]

It works when you delete the artifacts folder at the root of the solution. I have a "src", "samples" and "test" folders at the solution folder so I to do dnu restore at the level. I wish there's a way to filter out which directories to restore or better yet, which ones...

[guardrex]

Does listing the folder in the exclude section of project.json stop this behavior?

[codematrix]

@guardrex - Just tried, it doesn't work. - This is definitely a work in progress. At least there's a workaround - deleting the artifacts folder does the trick.

[guardrex]

@codematrix There is something for RTM that might solve this if it's still a prob for you when you get to RC2. https://github.com/dotnet/cli/issues/1588