ResolveAssemblyReference is slow on .NET Core with many references

[rainersigwald]

ResolveAssemblyReferences runs unconditionally even on incremental builds (because the user may have installed a targeting pack or, for full-framework scenarios, GACed an assembly). This makes it performance-sensitive.

With the advent of .NET Core micro-assemblies, it has become common to pass many, many references to RAR. This exacerbates performance problems.

@rynowak was kind enough to run a profiler to see this:

[rainersigwald]

One thing of note: MSBuild only calls that AssemblyName constructor because AssemblyName.Clone() isn't available in .NET Standard 1.x. One possible improvement here would be to move to .NET Core 2.0.

[rynowak]

To add a little more detail we really have a project that's taking this long to build (referring to the 95sec spent in UnifyAssemblyNameVersions).

You may want to check out https://github.com/aspnet/Mvc/tree/dev/test/Microsoft.AspNetCore.Mvc.FunctionalTests in general as example of a really complicated dotnet core package that's updated to the bleeding edge.

[eerhardt]

There's an ask from the ASP.NET team to not even run ResolveAssemblyReference in some cases. See dotnet/sdk#1193

[ericstj]

I think you should look at a couple options:

1. Caching immutable data (like metadata about a file inside a nuget package / targeting pack) to avoid recalculation from multiple processes / projects / rebuilds.
2. Identifying a fast path to skip RAR entirely and populate its outputs from a cache file in OBJ.

I think #2 is doable if we look at the right set of inputs/outputs and potentially change AssemblySearchPaths for some project types.