Sdk: Clarification on dotnet restore in solution with mixed old/new CSPROJ schema based projects

[am11]

dotnet restore in solution directory restores the dependencies of all the ".NET Core" projects in the solution. It does not restore the non-NetCore ones in the solution (the ones which are using old CSPROJ format with packages.config to enlist their dependencies).

nuget restore (where NUGET is v3.4, v3.5 or v4.0) in solution directory only restores the dependencies of non-NETCore projects, but does not understand the inline references in new CSPROJ schema (<PackageReference .. />).

After some experimentations, I have figured:

• Although running both nuget restore && dotnet restore addresses the problem, but if we instead use nuget restore && dotnet restore --packages ./packages, dotnet-restore clears the packages directory first which was populated by dotnet restore.
• Having packages.config for NETCore projects enlisting all the dependencies which we have in new CSPROJ (in the form of <PackageReference .. />); enables nuget restore to take care of restoration singlehandedly. Tested with NuGet v3.4, v3.5 and v4.0.

Can (/will) dotnet restore enumerate packages.configs in the projects, so we only need to use one tool to restore the packages in mixed solution scenarios?

---

dotnet --info

.NET Command Line Tools (1.0.0)

Product Information:
 Version:            1.0.0
 Commit SHA-1 hash:  e53429feb4

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\1.0.0

[livarcocc]

@am11 How does the build of such solution work? I am interested to learn more about these mixed solutions. Yours is the second issue we got about restore supporting packages.config, but when the other CLI verbs do not support old csproj style, it is not clear to me why support it from one verb if the other won't.

cc @emgarten

[am11]

@livarcocc,

We have different teams working on varied class library projects. Our repo has git submodule association with those, as our project depends on those libs and we compile all projects from source. Not all teams have their repos upgraded to the new csproj format.

In our SLN, we have included the old-csproj projects (from submodule directories) and our .NET Core app + an additional .NET Standard Library project.

For restore, nuget restore installs the dependencies for the old-csprojs (from their respective packages.config) and dotnet restore installs the dependencies for the new csprojs.

For build: MSBuild15 from CLI, and by proxy VS2017, figures out this heterogeneous dependency graph and compiles as usual; from most independent to the most dependent project. Internally, it probably calls the respective backends/SDKs based on the <Project ToolsVersion vs. <Project Sdk descriptors in the given csproj file. However, if we use dotnet build and even dotnet msbuild instead, we run into errors on building old csprojs like:

C:\repos\project\packages\Microsoft.Bcl.Build.1.0.21\build\Microsoft.Bcl.Build.targets(97,5):
error MSB4062: The "EnsureBindingRedirects" task could not be loaded from the assembly
C:\repos\project\packages\Microsoft.Bcl.Build.1.0.21\build\Microsoft.Bcl.Build.Tasks.dll.
Could not load file or assembly
'Microsoft.Build.Utilities.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct,
that the assembly and all its dependencies are available, and that the task contains a public class
that implements Microsoft.Build.Framework.ITask. [C:\repos\project\dependencies\d1\d1.csproj]

:: this happens after the full restore: dotnet resotre && nuget restore
:: right before or after this error, if we use `msbuild project.sln` VS2017,
:: the solution builds without errors

---

Like MSBuild15 from command line (and VS2017 form GUI) seamlessly build the entire solution with mixed project, would be nice if either of dotnet restore or nuget4.0 restore (or both! 💭) singlehandedly take care of the solution-wide package restore.

[emgarten]

@am11 you only need to run nuget.exe restore, it restores everything dotnet restore does and it also restores packages.config.

https://dist.nuget.org/win-x86-commandline/v4.0.0/nuget.exe

[am11]

@emgarten, you are right, Just clicked on the link and tested it worked! 😮 I thought I have nuget 4 in path (aliased nuget40), but it was actually pointing to nuget 3.5 😢

cd c:\repos\project
:: clean repo, start over
git clean -xdf && git submodule foreach "git clean -xdf"

:: with the real nuget4.0
nuget restore

:: builds happily with MSBuild15
"%ProgramFiles(x86)%\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild"

Thanks a lot! 👏

[mcm-ham]

Thanks @am11 for your final solution, note the last line can be replaced with dotnet msbuild.

Update
Sorry, that still gives EnsureBindingRedirects errors not sure why, calling msbuild directly like you have works.