NuGet / Home

Repo for NuGet Client issues
Other
1.5k stars 252 forks source link

Latest d15rel Visual Studio can't restore cross targeting projects #4496

Closed NTaylorMullen closed 7 years ago

NTaylorMullen commented 7 years ago

Details about Problem

image

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)):

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

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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

nguerrera commented 7 years ago

We can probably find a workaround in the SDK.

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

Eilon commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

SDK plans a clever fix: https://github.com/dotnet/sdk/issues/814

nkolev92 commented 7 years ago

This is fixed now.

Verified with 26206.0.d15rel