Consider caching toolset information in memory

[ladipro]

Issue Description

From @rainersigwald:
MSBuild stores “toolset” information in the .exe.config, which is used to populate default properties and do some other configuration. Today we will read that once per ProjectCollection — we can consider caching it for process lifetime since “manually editing msbuild.exe.config” is not a common/supported scenario and VS upgrades would always kill processes.

Steps to Reproduce

Create ProjectCollection and notice that several config files are read (machine.config, msbuild.exe.config).

Data

BytesRead(DuplicationFactor)	FilePath
1,323,008(~80.8x)	C:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\Current\Bin\amd64\MSBuild.exe.config

[nohwnd]

Caching the data would also affect reading machine.config which is read before the .exe.config.

BytesRead(DuplicationFactor)	FilePath
1,966,080(~49.1x)	C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config

[rainersigwald]

@nohwnd isn't machine.config a CLR thing? I don't see how we could affect that.

[nohwnd]

Under devenv.exe I saw it loaded when the .exe.config was loaded by System.Configuration. So reducing the number of times the .exe.config gets loaded by ProjectCollection, will reduce the number of times machine.config gets loaded.

[nohwnd]

This is how it looks like in my toy project just calling new ProjectCollection();

[rainersigwald]

Ah, interesting! We could probably avoid that by reading the configuration directly as XML rather than using System.Configuration; I don't think we really care about the extra stuff that provides over straight XML (other than "find the location of MSBuild.exe.config" which is doable).

[nohwnd]

Is that worth doing if you will cache it per process?

But I don't see any other way to avoid it. The OpenMappedExeConfiguration offers user level, None is provided, and that load machine.config, the others just try to resolve other config paths.