Feed implementation assemblies instead of their directories to ApiCompat

When invoking ApiCompat directly (without msbuild) and the implementation assemblies aren’t located in the same directory I would want to pass in the implementation assemblies directly instead of their directories. I assume that if I would pass in the implementation directories for each assembly, that would cause quite an overhead because of the Directory.GetFiles call per folder? Consider feeding 100+ assemblies in to it as an example.

Would it be possible to pass the implementation assemblies in directly?

Question for @safern and @ericstj

[ericstj]

I took a look at how the underlying implementation in APICompat handles paths here and it seems better.

Top-level comparisons must be specified through Assemblies. https://github.com/dotnet/sdk/blob/116d828644f7fcb4e85316844e6ee86a943b4aec/src/Compatibility/Microsoft.DotNet.ApiCompatibility/ApiComparer.cs#L50

Dependencies are stored in a dictionary by assembly name and directories are only probed if an assembly wasn’t explicitly specified. https://github.com/dotnet/sdk/blob/116d828644f7fcb4e85316844e6ee86a943b4aec/src/Compatibility/Microsoft.DotNet.ApiCompatibility/AssemblySymbolLoader.cs#L407-L436

So chances are we’ll get better perf here once exposing the option for files. I’ll leave this issue open for the folks implementing #18677 to serve as a reminder.

[ericstj]

It doesn’t actually enumerate the entire implementation directory. It just probes for the filenames that match the assembly names when loading assemblies. https://github.com/dotnet/arcade/blob/fd38a2e8191a46ddd6a559dbb52c9624989b2cf4/src/Microsoft.DotNet.ApiCompat/src/ApiCompatRunner.cs#L146-L151 https://github.com/microsoft/cci/blob/659f31f9736a1e8ded870ee2132d91f87505148e/CoreObjectModel/MetadataHelper/Core.cs#L467-L478

API Compat needs the assembly closure, so it uses directories to probe for dependencies when resolving type-defs. These might be more than the set of assemblies passed in.

I can see how if you passed it 100 directories it would get expensive, since it does consider each directory for every probe, but those are just exists checks that hit the file-system, not actual file reads nor file metadata when the file does not exist. Might not be a noticeable difference when compared to the actual file reads that happen once the assembly is located.

It’s feasible to support a static list of implementation assemblies that are used before probing the filesystem. I could see this as a separate parameter to API compat. One thing to be careful about is the load order. CCI needs to know the core-assembly and I recall us hitting problems in the past when refactoring the parameters that might change this.

I’m not certain how much we care about investing in CCI based API Compat right now. Our goal is to get the Roslyn based one up and running and supporting all the scenarios we care most about.