"Error occurred while restoring NuGet Package" and InvalidOperationException in Output window when the assembly name is different for different TFMs

[devinvisible]

I get the following message on the Package Manager Output window when I open my project in Visual Studio 2019 (16.2.2):

Error occurred while restoring NuGet packages: The operation failed as details for project Foo could not be loaded.

The same message precedes the 1>------ Rebuild All started: Project: Foo, Configuration: Release Any CPU ------ line on the Build Output window when I rebuild my project.

I see the following in my Tests Output window:

[8/14/2019 10:22:03.270 AM Informational] Store opened in 1.189 sec.
[8/14/2019 10:22:06.987 AM Error] System.InvalidOperationException: The operation failed as details for project Foo could not be loaded.
   at NuGet.PackageManagement.VisualStudio.NetCorePackageReferenceProject.GetPackageSpecsAsync(DependencyGraphCacheContext context)
   at NuGet.VisualStudio.VsPackageInstallerServices.<GetPackagesPathResolverAsync>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.VisualStudio.VsPackageInstallerServices.<>c__DisplayClass7_0.<<GetInstalledPackages>b__0>d.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 Microsoft.VisualStudio.Threading.JoinableTask.CompleteOnCurrentThread()
   at Microsoft.VisualStudio.Threading.JoinableTask`1.CompleteOnCurrentThread()
   at Microsoft.VisualStudio.Threading.JoinableTaskFactory.Run[T](Func`1 asyncMethod, JoinableTaskCreationOptions creationOptions)
   at NuGet.VisualStudio.VsPackageInstallerServices.GetInstalledPackages()
   at Microsoft.VisualStudio.TestWindow.Controller.UnitTestExtensionDiscoverer.GetNugetAdapters()
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.VisualStudio.Telemetry.WindowsErrorReporting.WatsonReport.GetClrWatsonExceptionInfo(Exception exceptionObject)
[8/14/2019 10:22:07.039 AM Informational] ---------- Discovery started ----------
[8/14/2019 10:22:07.182 AM Informational] ========== Discovery skipped: All test containers are up to date ==========

Here is my .csproj file:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFrameworks>net461;netcoreapp2.0</TargetFrameworks>
    <AssemblyName>Foo</AssemblyName>
    <SignAssembly>true</SignAssembly>
    <AssemblyOriginatorKeyFile>AwDotNetCore.snk</AssemblyOriginatorKeyFile>
    <GenerateAssemblyTitleAttribute>false</GenerateAssemblyTitleAttribute>
    <GenerateAssemblyCompanyAttribute>false</GenerateAssemblyCompanyAttribute>
    <GenerateAssemblyConfigurationAttribute>false</GenerateAssemblyConfigurationAttribute>
    <GenerateAssemblyDescriptionAttribute>false</GenerateAssemblyDescriptionAttribute>
    <GenerateAssemblyInformationalVersionAttribute>false</GenerateAssemblyInformationalVersionAttribute>
    <GenerateAssemblyProductAttribute>false</GenerateAssemblyProductAttribute>
    <GenerateAssemblyVersionAttribute>false</GenerateAssemblyVersionAttribute>
    <GenerateAssemblyFileVersionAttribute>false</GenerateAssemblyFileVersionAttribute>
    <GeneratePackageOnBuild>false</GeneratePackageOnBuild>
    <GenerateSerializationAssemblies>Off</GenerateSerializationAssemblies>
  </PropertyGroup>

  <PropertyGroup Condition="'$(TargetFramework)'=='net461'">
    <AssemblyName>Foo4</AssemblyName>
  </PropertyGroup>

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
    <Optimize>false</Optimize>
  </PropertyGroup>

  <ItemGroup Condition="'$(TargetFramework)'=='net461'">
    <Reference Include="System" />
    <Reference Include="System.Core" />
    <Reference Include="System.Data" />    
    <Reference Include="System.EnterpriseServices" />
    <Reference Include="System.Runtime.Remoting" />
    <Reference Include="System.Security" />
    <Reference Include="System.Web" />
    <Reference Include="System.Xml" />
  </ItemGroup>
  
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.Hosting.Abstractions" Version="2.0.0" />
    <PackageReference Include="Microsoft.AspNetCore.Http.Abstractions" Version="2.0.0" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc.Razor" Version="2.0.0" />
    <PackageReference Include="Microsoft.AspNetCore.Razor.Runtime" Version="2.0.0" />
    <PackageReference Include="Microsoft.Win32.Registry" Version="4.4.0" />
    <PackageReference Include="System.Data.SqlClient" Version="4.4.0" />
    <PackageReference Include="System.Security.Principal.Windows" Version="4.4.0" />
  </ItemGroup>
  
  <ItemGroup>
    <Compile Include="..\..\Version\generated\cpp\ProductVersion.cs">
      <Link>ProductVersion.cs</Link>
    </Compile>
  </ItemGroup>

</Project>

This seems to be related to the conditional PropertyGroup where the AssemblyName is different than the project name. When I remove the following lines from my .csproj file the errors go away:

  <PropertyGroup Condition="'$(TargetFramework)'=='net461'">
    <AssemblyName>Foo4</AssemblyName>
  </PropertyGroup>

[nkolev92]

Each PackageReference based NuGet powered project has what we call a PackageId, which defaults to AssemblyName.

Having a different PackageId is not a supported scenario.

Can you try setting PackageId to something that's same for both frameworks?

Few quick things:

1. I haven't tested this in VS yet, it's just my observation right now.
2. NuGet should try to provide a better error message, regardless of whether my hunch is correct :) We usually have more information.

[devinvisible]

@nkolev92 I added <PackageId>Foo</PackageId> to the first <PropertyGroup> in my .csproj (shared above). This appears to resolve the "Error occurred while restoring" and the InvalidOperationException seen on the Tests Output window.

This seems to work for me even when I conditionally change the <AssemblyName>.

[nkolev92]

Yeah, that makes sense.
PackageId takes preference over AssemblyName. AssemblyName is just the default.

I will rename a bit and leave this issue open to track the improvements for the error message shown.

[nkolev92]

Actually, looking at it again, the root cause is: #7717, but I'll still leave it open as this is particular to the error message actually shown.

[nkolev92]

#7717 is actively worked on.

Closing as dup.

cc @zivkan #7717