ResolvePackageAssets failed for Microsoft.DotNet.CoreMcg.1.0.0-prerelease-0005

[cshung]

The Nuget package in question is hosted on the https://dotnet.myget.org/gallery/dotnet-buildtools feed named Microsoft.DotNet.CoreMcg.

After Nuget restore, a file named project.assets.json is created. The ".NETCoreApp,Version=v1.0" node contains 111 children and so is the ".NETCoreApp,Version=v1.0/win-arm" node. The number of libraries is identical.

This tripped the condition in ResolvePackageAssets.cs:

if (_compileTimeTarget.Libraries.Count >= _runtimeTarget.Libraries.Count)
{
    WriteItem(string.Format(Strings.UnsupportedRuntimeIdentifier, _task.RuntimeIdentifier));
    WriteMetadata(MetadataKeys.Severity, nameof(LogLevel.Error));
}

Why must the _compileTimeTarget.Libraries.Count strictly less than _runtimeTarget.Libraries.Count, in particular, wouldn't the two numbers equal a fine thing as well?

[dsplaisted]

We do expect there to be strictly more assets when you have a runtime identifier (RID) specified. Without a RID specified, the app is framework-dependent and will run using the installed .NET Core shared framework. If you want to carry the .NET Core runtime with your app, then you can specify the RID and by default it will be published as self-contained. So if a RID is specified we expect to have the additional assets that come from the .NET Core runtime.

Can you provide a full repro project so we can better understand what you're trying to do?

[nguerrera]

Note that win-arm was not supported by .net core 1.0 so the error is by design when setting this RID while targeting 1.0.

Why are you setting this RID and targeting 1.0?

[cshung]

Thanks for the help, your comment is helpful in resolving the problem, we have solved the problem.

In a nutshell, I believe it is our build script that is confused about the package. The package we need to use is only a build time tool, but it passed in the RID of the environment where the built binaries will run.

The code does confuse me though, when I investigate the build failure, it was unclear to me that the comparison isn't a bug, especially so in the case of ==. It would nice to add a comment (or more useful error message) on why are we comparing the count of libraries.