Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

dotnet migrate fails on Linux if app directory is directly under a folder with a cyclic symlink

See original GitHub issue

dotnet migrate fails on Linux if the app directory is directly under root (e.g. /app). It’s easy to repro with docker containers, but it should also repro on the host OS.

It repros when using microsoft/dotnet-nightly:1.1.0-sdk-msbuild-rc4 or later. It works fine when using microsoft/dotnet:1.1.0-sdk-msbuild-rc3.

It also works fine if the app directory is two levels below root (e.g. /src/app).

Steps to reproduce

mkdir ~/new

docker run -it --rm -v ~/new:/new microsoft/dotnet:1.1.0-sdk-projectjson
cd new
dotnet new

docker run -it --rm -v ~/new:/new microsoft/dotnet-nightly:1.1.0-sdk-msbuild-rc4
cd new
dotnet migrate

Expected behavior

App is migrated from project.json to MSBuild.

Actual behavior

dotnet migrate will either hang or throw the following exception:

root@08dd3e787323:/new# dotnet migrate
Migration failed.

Unhandled Exception: System.IO.DirectoryNotFoundException: Could not find a part of the path '/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/root/proc/7/fd/78'.
   at System.IO.UnixFileSystem.FileSystemEnumerable`1.OpenDirectory(String fullPath)
   at System.IO.UnixFileSystem.FileSystemEnumerable`1.<Enumerate>d__11.MoveNext()
   at System.Collections.Generic.EnumerableHelpers.ToArray[T](IEnumerable`1 source, Int32& length)
   at System.IO.DirectoryInfo.InternalGetDirectories(String searchPattern, SearchOption searchOption)
   at System.IO.DirectoryInfo.GetDirectories(String searchPattern, SearchOption searchOption)
   at Microsoft.DotNet.ProjectJsonMigration.ProjectDependencyFinder.GetPotentialProjects(IEnumerable`1 searchPaths)
   at Microsoft.DotNet.ProjectJsonMigration.ProjectDependencyFinder.FindPossibleProjectDependencies(SlnFile slnFile, String projectJsonFilePath)
   at Microsoft.DotNet.ProjectJsonMigration.ProjectDependencyFinder.ResolveDirectProjectDependenciesForFramework(Project project, NuGetFramework framework, IEnumerable`1 preResolvedProjects, SlnFile solutionFile)
   at Microsoft.DotNet.ProjectJsonMigration.ProjectDependencyFinder.ResolveAllProjectDependenciesForFramework(ProjectDependency projectToResolve, NuGetFramework framework, IEnumerable`1 preResolvedProjects, SlnFile solutionFile)
   at Microsoft.DotNet.ProjectJsonMigration.Rules.MigrateProjectDependenciesRule.MigrateProjectJsonProjectDependency(Project project, NuGetFramework framework, HashSet`1 migratedXProjDependencyNames, SlnFile solutionFile, ProjectRootElement outputMSBuildProject)
   at Microsoft.DotNet.ProjectJsonMigration.Rules.MigrateProjectDependenciesRule.MigrateProjectJsonProjectDependencies(IEnumerable`1 projectContexts, HashSet`1 migratedXProjDependencyNames, SlnFile solutionFile, ProjectRootElement outputMSBuildProject)
   at Microsoft.DotNet.ProjectJsonMigration.Rules.MigrateProjectDependenciesRule.Apply(MigrationSettings migrationSettings, MigrationRuleInputs migrationRuleInputs)
   at Microsoft.DotNet.ProjectJsonMigration.DefaultMigrationRuleSet.Apply(MigrationSettings migrationSettings, MigrationRuleInputs migrationRuleInputs)
   at Microsoft.DotNet.ProjectJsonMigration.ProjectMigrator.MigrateProject(MigrationSettings migrationSettings)
   at Microsoft.DotNet.ProjectJsonMigration.ProjectMigrator.Migrate(MigrationSettings rootSettings, Boolean skipProjectReferences)

   at Microsoft.DotNet.Tools.Migrate.MigrateCommand.Execute()
   at Microsoft.DotNet.Tools.Migrate.MigrateCommand.<>c__DisplayClass35_0.<Run>b__0()
   at Microsoft.DotNet.Cli.CommandLine.CommandLineApplication.Execute(String[] args)
   at Microsoft.DotNet.Tools.Migrate.MigrateCommand.Run(String[] args)
   at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, ITelemetry telemetryClient)
   at Microsoft.DotNet.Cli.Program.Main(String[] args)
Aborted (core dumped)

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-rc4-004757)

Product Information:
 Version:            1.0.0-rc4-004757
 Commit SHA-1 hash:  f69f0ed266

Runtime Environment:
 OS Name:     debian
 OS Version:  8
 OS Platform: Linux
 RID:         debian.8-x64
 Base Path:   /usr/share/dotnet/sdk/1.0.0-rc4-004757

Issue Analytics

  • State:closed
  • Created 7 years ago
  • Comments:7 (7 by maintainers)

github_iconTop GitHub Comments

mikehardercommented, Feb 3, 2017

Thanks, that worked. I will update this issue with the correct root cause: dotnet migrate fails if the app directory is at the root. This is a fairly common pattern in docker containers (e.g. see the instructions at

livarcocccommented, Feb 3, 2017

Ok, I understand why this happens. This happens because you created your new project at the root of the docker machine. If you create something like src/new and then put your project there, it will work.

Migration looks at the parent folder you are migration migration at, in this case / so that it can find dependencies for your project, which is why we are hitting this issue.

We had to add the GetDirectories call with SearchOptions.AllDirectories so that we could actually find dependencies for a project that were deeper on the folder structure than the project itself.

Can you try the work around I suggested?

Read more comments on GitHub >

github_iconTop Results From Across the Web

Dotnet CLI fails building after mv to other directory?
I've tried them seperately and found out that the 'dotnet build' command gives the error. The git repo was completely empty, I just...
Read more >
Too many levels of symbolic links
Use the absolute path instead of the relative path, then it will work. Eg: ln -s /home/user/test/src /home/user/test/firefox.
Read more >
What happens to a symbolic link when the original file is ...
I have update software in /opt/minergate-cli . I've renamed the directory minergate-cli to minergate-old with an mv command, then installed a ...
Read more >
How do I resolve a "Too many levels of symbolic links ...
I am using the latest Deepin 15.11, and have just discovered that I cannot access my Documents folder (/home/username/Documents).
Read more >
FAQ — Syncthing documentation
Does Syncthing support syncing between folders on the same system? When I do have two distinct Syncthing-managed folders on two hosts, how does...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found