Closed NTaylorMullen closed 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
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.
@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.
@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.
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. :(
Sure would be nice if only the MSBuild logic that your project needed was loaded...
We can probably find a workaround in the SDK.
I am curious why msbuild /t:restore works but restore in IDE doesn't.
@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.
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.
SDK plans a clever fix: https://github.com/dotnet/sdk/issues/814
This is fixed now.
Verified with 26206.0.d15rel
Details about Problem
dotnet.exe --version (if appropriate): From Package Manager Console to see what VS was using
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
<TargetFramework>netcoreapp1.0</TargetFramework>
to<TargetFrameworks>net451;netcoreapp1.0</TargetFrameworks>
.ClassLibrary1.sln
.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:
Sample Project
ClassLibrary1.zip - Just re-linked from above.