Latest d15rel Visual Studio can't restore cross targeting projects

[NTaylorMullen]

Details about Problem

dotnet.exe --version (if appropriate):
From Package Manager Console to see what VS was using

Package Manager Console Host Version 4.0.0.2259

Type 'get-help NuGet' to see all available NuGet commands.

PM> dotnet --info
.NET Command Line Tools (1.0.0-rc4-004755)

Product Information:
 Version:            1.0.0-rc4-004755
 Commit SHA-1 hash:  bffbee2b91

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Users\nimullen\AppData\Local\Microsoft\dotnet\sdk\1.0.0-rc4-004755

OS version (i.e. win10 v1607 (14393.321)):

• Win10 Enterprise 14393.693

Worked before? If so, with which NuGet version:
Yes, after updating Visual Studio 2 days ago this started breaking.

Detailed repro steps so we can see the same problem

• Download ClassLibrary1.zip. It's just a file => new class library where I changed the <TargetFramework>netcoreapp1.0</TargetFramework> to <TargetFrameworks>net451;netcoreapp1.0</TargetFrameworks>.
• Open ClassLibrary1.sln.
• If it doesn't auto restore (seems inconsistent on my end) force a restore on the sln.
• You will get Error occurred while restoring NuGet packages: The operation failed as details for project ClassLibrary1 could not be loaded.

Other Information

Changing back to <TargetFramework>netcoreapp1.0</TargetFramework> or <TargetFramework>net451<TargetFramework> then makes the Visual Studio experience work. Also, if you restore at command line before opening in VS everything works fine. You can definitely work around this issue but it's quite frustrating 😄

Verbose Logs

Turned MSBuild logs to be more diagnostic and I was able to get the following call stack:

Error occurred while restoring NuGet packages: System.InvalidOperationException: The operation failed as details for project ClassLibrary1 could not be loaded.
   at NuGet.PackageManagement.VisualStudio.CpsPackageReferenceProject.GetPackageSpecsAsync(DependencyGraphCacheContext context)
   at NuGet.PackageManagement.DependencyGraphRestoreUtility.<GetSolutionRestoreSpec>d__8.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.PackageManagement.DependencyGraphRestoreUtility.<IsRestoreRequiredAsync>d__6.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.SolutionRestoreManager.SolutionRestoreJob.<RestorePackageSpecProjectsAsync>d__17.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
   at NuGet.SolutionRestoreManager.SolutionRestoreJob.<RestoreAsync>d__15.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at NuGet.SolutionRestoreManager.SolutionRestoreJob.<RestoreAsync>d__15.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at NuGet.SolutionRestoreManager.SolutionRestoreJob.<ExecuteAsync>d__14.MoveNext()

Sample Project

ClassLibrary1.zip - Just re-linked from above.

[rrelyea]

this is a migration problem.
we cannot fix...we need one version defined for a project...and the innerbuilds needs to have the same answer...cause we cannot arbitrarily pick.

Please chime in on: https://github.com/dotnet/cli/issues/5573 -- which is currently not RTM.
you'll know workaround, but can push for migration fix if you think it is necessary.

@livarcocc @srivatsn @dsplaisted @nguerrera @eerhardt @alpaix

[livarcocc]

This is not a migration issue rob. See @NTaylorMullen's repro above. He reached this issue through a File -> New class library and edited his project to be Multi TFM.

[rrelyea]

@NTaylorMullen - can you make sure that each TFM evaluates PackageVersion to the same version.
Otherwise, we don't know which version to write into the assets file.

[Eilon]

@rrelyea can you please mark as "blocking partner" (however that's done in this repo) so that it shows up in the queries we use for Tools Daily Standup?

Rob: done.

[nguerrera]

OK, did some digging. Microsoft.WinFX.targets on net451 is setting Version to 1.0.0.0 where the SDK would have defaulted it to 1.0.0. This is why it differs between target frameworks. :(

[eerhardt]

Sure would be nice if only the MSBuild logic that your project needed was loaded...

[nguerrera]

We can probably find a workaround in the SDK.

I am curious why msbuild /t:restore works but restore in IDE doesn't.

[Eilon]

@rrelyea BTW to be clear, there are no "explicit" package refs at all, just the implied standard library ref that becomes available based on the TFM(s) in the project.

[nguerrera]

This would also cause VersionPrefix not to work on net4x. A fix in the SDK would be to move all Version defaulting to BeforeCommon/BeforeCommonCrossTargeting. The WinFX defaulting checks if it's not already set and it would then come later.

[rrelyea]

SDK plans a clever fix: dotnet/sdk#814

[nkolev92]

This is fixed now.

Verified with 26206.0.d15rel