Cache NativeAOT Visual Studio tool discovery#129316
Conversation
Run vswhere during Windows NativeAOT setup to validate the selected Visual Studio installation and reuse cached vcvarsall output when the installation path and version match. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
Tagging subscribers to this area: @agocke, @dotnet/ilc-contrib |
There was a problem hiding this comment.
Pull request overview
This PR updates the Windows NativeAOT build integration to discover Visual Studio toolchains via vswhere.exe and cache the derived vcvarsall.bat output (tool directory + LIB paths) in $(NativeIntermediateOutputPath) so subsequent builds can reuse it.
Changes:
- Replace the
findvcvarsall.batinvocation with in-targetvswhere.execalls to locate the VS installation path/version and compute the appropriatevcvarsallenvironment. - Add a per-architecture cache file (
findvcvarsall.$(_targetArchitecture).txt) to reuse priorvcvarsalloutput when the VS path/version match. - Remove the now-unused
findvcvarsall.batscript.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.Windows.targets | Implements vswhere-based VS discovery and a cache file to reuse vcvarsall output. |
| src/coreclr/nativeaot/BuildIntegration/findvcvarsall.bat | Deleted (logic is now embedded in the .targets file). |
|
@eduardo-vp could you have a look at this? it basically inlines the findvcvarsall into MSBuild and introduces caching. Before this change, we were guaranteed to spend a second of the build in findvcvarsall, even in incremental do nothing scenarios. Now incremental builds take ~100 ms (running vswhere takes ~50 ms by itself and we run it twice). |
Fixes #129265
Run vswhere during Windows NativeAOT setup to validate the selected Visual Studio installation and reuse cached vcvarsall output when the installation path and version match.