search

dotnet / project-system

The .NET Project System for Visual Studio
MIT License
968 stars 386 forks source link

Update "Build VS Bootstrapper" #9376

Closed tmeschter closed 8 months ago

tmeschter commented 8 months ago

Related to AB#1939807.

To perform partial NGEN of our installed assemblies--where NGEN only pre-JITs the methods we need for a scenario, rather than every method--we need optimization data produced by OptProf runs. We run our own little test that produces this optimization data on every scheduled build of our main branch. This test is pretty straightforward--it loads a solution with a handful of projects in VS. We run the test out of our main branch so that it can incorporate our latest changes without the need for us to insert into VS. However, this means the test needs to install and run a build of VS that actually has those changes. We accomplish this with the MicroBuildBuildVSBootstrapper task. We give it a build channel and it uses the latest build from that channel as a baseline. We also point it at our locally-produced .vsman file describing our setup components, and it merges the two to produce a new VS installer (e.g. vs_enterprise.exe) that combines the two.

The channel we specify in this "Build VS Bootstrapper" task is "int.main" which tracks builds out of the VS "main" branch. This is generally what we want as most of our builds and insertions are from the dotnet/project-system "main" branch into the VS "main" branch. However, it is completely wrong when it comes to release/servicing branches. In the case of our "dev17.8.x" branch, for example, we're producing binaries that target the 17.8 release of VS but end up incorporating them into an installer based on VS "main", which is currently a 17.10 branch. This results in our package not loading properly, which in turn means the test fails and any optimization data we produce does not cover our assemblies. Without that data we get full NGEN of our assemblies at install-time.

Since the "dev17.8.x" branch is a 17.8 servicing branch, this commit updates us to target the "int.rel/d17.8" channel instead. This means the installer will be based on builds out of the VS "rel/d17.8" branch, which is what we want.

Microsoft Reviewers: Open in CodeFlow
drewnoakes commented 8 months ago

@tmeschter should we include this as a step on our branch check list?

tmeschter commented 8 months ago

@drewnoakes Yeah, I had the same thought. I'm going to update that once I actually get this working again.