Repository navigation
Is filename being different to assembly name a practical edge case? #433
Description
I asked copilot to profile ilrepack while it's building NuGet.exe, and look for performance improvements. The biggest improvement it suggested was regarding RepackAssemblyResolver.ReadRuntime. It loads *.dll and populates assemblyPathsByFullAssemblyName with a mapping of assembly name to file name.
In theory, an assembly's filename doesn't have to match the assembly name. But then the app.config needs an entry with a codebase to tell the assembly prober what the real filename is, or the app needs code to use Assembly.LoadFrom, or similar, to load it from the real filename. Although, Assembly.LoadFrom won't be happening for an ilrepacked app.
So, I acknowledge that loading *.dll and loading the metadata to find the real assembly name is technically the right thing to do to work in all edge cases. But when I asked copilot to implement a perf improvement, ilrepack was 20% faster for NuGet.exe. That's big enough that I'd like to start a conversation about the idea.
Visual Studio is the most complex .NET app I'm aware of, and looking at *.dll in my VS install directory, the only files where the assembly name doesn't match the filename are a few ServiceHub.*.dll hosts. But they have a Program.Main entry point, so the CLR assembly loader will never need to discover it as a reference. I'm unable to find an example of when an assembly name is different to the file name, so I'm wondering if ilrepack could take advantage of the practical constraint and take the 20% perf improvement. If not by default, then via some /switch.
An alternative is to change ReadRuntime to enumerate the files in parallel. A quick test showed it was 10% faster on my machine, for NuGet.exe.
Activity