Migrating a pure dotnet-core project does not create a solution

[livarcocc]

From @nlowe on February 15, 2017 3:3

Steps to reproduce

dotnet migrate on a project that only contains project.json projects (example)

Expected behavior

The projects are migrated to csproj and a solution is created OR the tool chain allows multiple projects to be specified as before.

Actual behavior

The projects are migrated, but a solution is not created. This means there is no easy way to restore and build, since dotnet restore only allows you to specify one project at a time and dotnet build seems to want a solution now instead of searching for projects. Perhaps I missed a communication?

Environment data

dotnet --info output:

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

Product Information:
 Version:            1.0.0-rc4-004771
 Commit SHA-1 hash:  4228198f0e

Runtime Environment:
 OS Name:     arch
 OS Version:  
 OS Platform: Linux
 RID:         ubuntu.14.04-x64
 Base Path:   /opt/dotnet/sdk/1.0.0-rc4-004771

Copied from original issue: dotnet/cli#5714

[livarcocc]

From @piotrpMSFT on February 15, 2017 6:37

@nlowe great suggestion!

For the time being, your scenario should still work. When we migrate multiple related project.json projects we wire up appropriate references between them. That allows you to go to the root project, the one no other project depends on, and restore and build it. The tools are smart enough to determine that dependencies of that project also need to be restored & built and they do that automatically!

I'm putting the suggestion in 2.0.0 milestone. This would be cool to provide, at least as an option.

[livarcocc]

From @nlowe on February 15, 2017 19:27

Correct, but I still have to do something like find . -type f -name '*.csproj' -exec dotnet restore {} \; whereas previously I could just issue dotnet restore from the project root. I can adapt build scripts (cake), but I still feel this is a loss of functionality.

Additionally, it seems dotnet build **/*.csproj no longer works. IIRC you used to be able to dotnet build **/project.json.

From what I understand, creating a solution should resolve this, but unless you hack one together manually I think you need to use Visual Studio (not available on linux) or Jetbrains Rider or something similar

[livarcocc]

From @dasMulli on February 15, 2017 19:30

Luckily, you no longer need to hack one together manually 😄 🎉

MacBook-Pro:foobar martin$ dotnet new solution
Content generation time: 20.3027 ms
The template "Solution File" created successfully.
MacBook-Pro:foobar martin$ dotnet sln add **/*.csproj
Project `app1/app1.csproj` added to the solution.
Project `app2/app2.csproj` added to the solution.

[livarcocc]

From @nlowe on February 15, 2017 19:36

Is file globbing broken in linux?

[nathan@nathan-arch netcore-multiproject]$ dotnet sln add **/*.csproj
Project `**/*.csproj` does not exist.
.NET Add project(s) to a solution file Command

Usage: dotnet sln <SLN_FILE> add [options] [args]

Arguments:
  <SLN_FILE>  Solution file to operate on. If not specified, the command will search the current directory for one.

Options:
  -h|--help  Show help information

Additional Arguments:
 Add a specified project(s) to the solution.

[nathan@nathan-arch netcore-multiproject]$ tree
.
├── backup
│   ├── global.json
│   ├── src
│   │   ├── MyProject
│   │   │   └── project.json
│   │   ├── MyProject.Types
│   │   │   ├── MyProject.Types.csproj
│   │   │   ├── obj
│   │   │   │   ├── MyProject.Types.csproj.nuget.g.props
│   │   │   │   ├── MyProject.Types.csproj.nuget.g.targets
│   │   │   │   └── project.assets.json
│   │   │   └── project.json
│   │   └── MyProject.Web
│   │       └── project.json
│   └── test
│       └── MyProject.Tests
│           └── project.json
├── build.cake
├── build.ps1
├── build.sh
├── netcore-multiproject.sln
├── src
│   ├── MyProject
│   │   ├── MyProject.csproj
│   │   └── Program.cs
│   ├── MyProject.Types
│   │   ├── Library.cs
│   │   ├── MyProject.Types.csproj
│   │   └── obj
│   │       ├── MyProject.Types.csproj.nuget.g.props
│   │       ├── MyProject.Types.csproj.nuget.g.targets
│   │       └── project.assets.json
│   └── MyProject.Web
│       ├── bower.json
│       ├── Controllers
│       │   └── TestController.cs
│       ├── MyProject.Web.csproj
│       ├── package.json
│       ├── Program.cs
│       ├── Properties
│       │   └── launchSettings.json
│       ├── README.md
│       ├── Startup.cs
│       ├── Views
│       │   ├── Shared
│       │   │   └── _Layout.cshtml
│       │   ├── Test
│       │   │   └── Index.cshtml
│       │   └── _ViewStart.cshtml
│       └── web.config
├── test
│   └── MyProject.Tests
│       ├── MyProject.Tests.csproj
│       └── Tests.cs
└── tools
    └── nuget.exe

21 directories, 35 files

EDIT: I also tried dotnet sln netcore-multiproject.sln add **/*.csproj as suggested by the error message, same result.

This worked however:

[nathan@nathan-arch netcore-multiproject]$ find . -type f -name '*.csproj' -exec dotnet sln add {} \;
Project `backup/src/MyProject.Types/MyProject.Types.csproj` added to the solution.
Project `test/MyProject.Tests/MyProject.Tests.csproj` added to the solution.
Project `src/MyProject/MyProject.csproj` added to the solution.
Project `src/MyProject.Types/MyProject.Types.csproj` added to the solution.
Project `src/MyProject.Web/MyProject.Web.csproj` added to the solution.

[livarcocc]

From @nlowe on February 15, 2017 19:43

Also, should the solution file really be marked executable?

-rwxr--r--  1 nathan nathan 5.5K Feb 15 14:42 netcore-multiproject.sln

[livarcocc]

From @dasMulli on February 15, 2017 19:51

The executable thing is a standing issue with .net.. there are issues both on the cli and corefx for it.

Globbing should be done by the shell here so it probably depends on the shell version and settings (bash 3.2.57(1) on Mac OS in my case). So you could also do it via find . -type f -name '*.csproj' -exec dotnet sln add {} \;