So I was debugging the performance of msbuild's resolve assembly reference and it turns out that it is doing more work because our facade assemblies reference 0.0.0.0 versions of all their dependencies. What happens is that we give RAR a set of primary assemblies from:
%userprofile%.nuget\packages\microsoft.netcore.app\2.0.0\ref\netcoreapp2.0
Some of these assemblies are facades that have reference assemblies of version 0.0.0.0. As an example, here's what System.dll looks like in ILSpy:
This causes RAR to think that it's discovering new assemblies and as a result ends up walking the graph 23 times for a new .NET Core console project. This ends up adding 111 new "unresolved references" to the reference table that msbuild then attempts to resolve from various locations.
Microsoft.NETCore.App is a full closure of assemblies and it should provide that closure to msbuild with the correct versions so that only a single pass in required.
/cc @ericstj @eerhardt @weshaggard @davkean @cdmihai
So I was debugging the performance of msbuild's resolve assembly reference and it turns out that it is doing more work because our facade assemblies reference 0.0.0.0 versions of all their dependencies. What happens is that we give RAR a set of primary assemblies from:
%userprofile%.nuget\packages\microsoft.netcore.app\2.0.0\ref\netcoreapp2.0
Some of these assemblies are facades that have reference assemblies of version 0.0.0.0. As an example, here's what System.dll looks like in ILSpy:
This causes RAR to think that it's discovering new assemblies and as a result ends up walking the graph 23 times for a new .NET Core console project. This ends up adding 111 new "unresolved references" to the reference table that msbuild then attempts to resolve from various locations.
Microsoft.NETCore.App is a full closure of assemblies and it should provide that closure to msbuild with the correct versions so that only a single pass in required.
/cc @ericstj @eerhardt @weshaggard @davkean @cdmihai