{11:51}~/test âž dotnet new sln -n fsharpsolution
Content generation time: 60.1264 ms
The template "Solution File" created successfully.
{11:51}~/test âž dotnet new console -lang F# -n proj1
Content generation time: 111.1087 ms
The template "Console Application" created successfully.
{11:51}~/test âž dotnet sln add proj1/proj1.fsproj
Project `proj1/proj1.fsproj` added to the solution.
{11:51}~/test âž dotnet restore
/opt/dotnet/sdk/1.0.4/NuGet.targets(97,5): warning : Unable to find a project to restore! [/home/[email protected]/test/fsharpsolution.sln]
{11:52}~/test âž cat /etc/redhat-release && dotnet --version
CentOS Linux release 7.2.1511 (Core)
1.0.4
NOTE: Also tested using linux subsystem on windows 10 with Ubuntu 14.04.5 LTS and dotnet version 1.0.4 and got same results
All F# projects in solution should be able to restore and build.
No F# projects are found in solution to restore.
dotnet --info output:
[cnikkel@syslog test]$ dotnet --info
.NET Command Line Tools (1.0.4)
Product Information:
Version: 1.0.4
Commit SHA-1 hash: af1e6684fd
Runtime Environment:
OS Name: centos
OS Version: 7
OS Platform: Linux
RID: centos.7-x64
Base Path: /opt/dotnet/sdk/1.0.4
```AND```
{11:57}~/test âž dotnet --info
.NET Command Line Tools (1.0.4)
Product Information:
Version: 1.0.4
Commit SHA-1 hash: af1e6684fd
Runtime Environment:
OS Name: ubuntu
OS Version: 14.04
OS Platform: Linux
RID: ubuntu.14.04-x64
Base Path: /usr/share/dotnet/sdk/1.0.4
Same issue here on macOS with dotnet SDK 1.0.4. Apparently it only works on Windows but not on Unix system. Restoring project by project works though.
i can repro too
I fixed this by changing all the project path strings to use / instead of \ in my .sln file. Seems the command: dotnet sln add path-to-project adds backslashes by default.
While i can repro in 1.0.4, this is fixed in 2.0.0-preview2 (tested also in https://github.com/dotnet/cli/pull/6977 )
As a note, the sln will use \ directory separator, but restore will work
@livarcocc the 1.0.x branch is getting an update? if so, i can try backport the fix (if i can find it).
@enricosada we are not servicing 1.0.0 or 1.0.1 anymore. Instead, we are servicing 1.1.0 from now on. Though, with 2.0.0 release and backwards compatible with 1.0 projects, do we still needs this fix for 1.1.0? If not, I would like to close this issue.
2.0.0 works great for me. I don't see any value in keeping this issue open.
Awesome, thanks for letting us know.