Home: Nuget Restore fails when project has multiple target frameworks and conditional assembly names

[Pilchie]

_From @ChristopherHaws on January 18, 2018 17:14_

When targeting multiple frameworks and having different assembly names for the output assembly, Visual Studio fails to restore the packages.

The error I receive in the output window of Visual Studio is:

C:\Program Files\dotnet\sdk\2.1.4\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(167,5): error : Assets file 'c:\Projects\Test\obj\project.assets.json' doesn't have a target for '.NETCoreApp,Version=v2.0'. Ensure that restore has run and that you have included 'netcoreapp2.0' in the TargetFrameworks for your project.

My csproj file looks like this:

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

  <PropertyGroup>
    <TargetFrameworks>net462;netcoreapp2.0</TargetFrameworks>

    <AssemblyName Condition=" '$(TargetFramework)' == 'net462' ">assembly.name</AssemblyName>
    <AssemblyName Condition=" '$(TargetFramework)' == 'netcoreapp2.0' ">assembly.name.dotnetcore</AssemblyName>
  </PropertyGroup>

</Project>

Something to note, I am able to restore and build using the CLI, but not Visual Studio.

I have tried this in:
Visual Studio Enterprise 2017 15.5.3
Visual Studio Enterprise 2017 15.5.4
Visual Studio Enterprise 2017 15.6.0 Preview 2.0

_Copied from original issue: dotnet/project-system#3160_

[Pilchie]

@natidea @rrelyea @emgarten - should this go to NuGet or here?

[Pilchie]

_From @emgarten on January 18, 2018 22:53_

My guess is that NuGet blocks the nomination here because the asssembly name is different. NuGet uses the assembly name as the id of the project, and this flows transitively to parent projects.

Having a different id for each TFM isn't supported because it would be like having a nupkg with multiple ids.

The workaround here would be to set <PackageId>assembly.name</PackageId> so that NuGet doesn't fall back to reading the AssemblyName property.

[Pilchie]

Thanks - I'll move to NuGet/Home.

[emgarten]

I think the fix here would be to surface an error to the user. I don't know think we can just pick the first possible name provided.

[ChristopherHaws]

Adding the <PackageId> field per @Pilchie 's post does indeed fix the issue.

@emgarten I agree, having a better error message would help a lot. Perhaps having PackageId fallback to the MSBuildProjectName if there are multiple assembly names could be another option.

[clairernovotny]

I'm not sure that surfacing an error to the user is a good option here. That seems to be exposing an implementation detail (that somewhere it treats the assembly name as id of the project) to the user. Seems like the implementation is leaking out.

I would agree that an error is valid if a user tries to Pack a project that depends on a project with multiple assembly names if there's no ID set, but I would not assume every p2p reference is intended to be packed.

[magol]

I have the same problem, see #5222

[nkolev92]

Related to #7717

[shyamnamboodiripad]

Folks on my team are running into a slightly different error inside VS than what is mentioned in the issue description above. However, per offline conversation with @nkolev92 the underlying issue is the same and the same workaround of specifying a PackageId helps avoid the error.

NuGet package restore failed. Please see Error List window for detailed warnings and errors.
Error occurred while restoring NuGet packages: Invalid restore input. Missing required property 'Name'. Input files: D:\VSUnitTesting\src\Fakes\Src\Compilation\Console.x86\fakes.x86.csproj.

I realize this is a lower priority issue, but I just wanted to add my vote to fix this, as the error is quite opaque and the workaround even more so. @AbhitejJohn and myself have been scratching our heads trying to figure out which 'Name' property the error is complaining about 😄

Even though the error doesn't break build, I find it quite annoying. Seeing any line in the build output that begins with Error throws me off - every once in a while I am fooled into thinking I have some compilation error before quickly realizing its the above error that I can ignore...

Also, the error is displayed even when building unrelated projects in the solution graph - so it ends up in the output of almost every build...