Disable Build Acceleration for known incompatible packages #9214
Conversation
While rare, it's possible for a NuGet package to include `.props` and/or `.targets` files that customise the build in a way that's not compatible with Build Acceleration. Ideally such packages would also set `AccelerateBuildsInVisualStudio` to `false`, however that's not always an option.
To address this situation, this change introduces the ability to specify NuGet packages that, when present in a project, will disable Build Acceleration.
We add one known package (`Microsoft.VSSDK.BuildTools`, for VSIX projects) to our design-time `.targets` file, but SDKs and customers may add their own items too.
For example, if `MyPackage` is known to be incompatible with Build Acceleration, adding a `BuildAccelerationIncompatiblePackage` item to your `Directory.Build.props` will automatically cause Build Acceleration to be disabled for any project that references that `MyPackage`:
```xml
<Project>
<PropertyGroup>
<AccelerateBuildsInVisualStudio>true</AccelerateBuildsInVisualStudio>
</PropertyGroup>
<ItemGroup>
<BuildAccelerationIncompatiblePackage Include="MyPackage" />
</ItemGroup>
</Project>
```
When a project is found to have an incompatible project reference, the FUTDC log displays a message to that effect, such as:
> Build acceleration has been disabled for this project due to known incompatible NuGet package reference(s) 'Microsoft.VSSDK.BuildTools'. See https://aka.ms/vs-build-acceleration.
drewnoakes
added
the
Feature-Build-Acceleration
| <!-- Disable Build Acceleration for VSIX projects --> | ||
| <AccelerateBuildsInVisualStudio Condition="'$(IsVsixProject)' == 'true'">false</AccelerateBuildsInVisualStudio> |
There was a problem hiding this comment.
This never really worked property. Turns out that IsVsixProject is our own property, not one defined in Microsoft.VSSDK.BuildTools's .props or .targets.
| <!-- Collect packages that are incompatible with Build Acceleration. --> | ||
| <PropertyGroup Condition="'$(CollectBuildAccelerationIncompatiblePackageDesignTimeDependsOn)' == ''"> | ||
| <CollectBuildAccelerationIncompatiblePackageDesignTimeDependsOn></CollectBuildAccelerationIncompatiblePackageDesignTimeDependsOn> | ||
| </PropertyGroup> | ||
| <Target Name="CollectBuildAccelerationIncompatiblePackageDesignTime" DependsOnTargets="$(CollectBuildAccelerationIncompatiblePackageDesignTimeDependsOn)" Returns="@(BuildAccelerationIncompatiblePackage)" /> |
There was a problem hiding this comment.
This allows extenders to add more items in targets, should they need to. I expect most additions to BuildAccelerationIncompatiblePackage would be done via evaluation though.
| <Rule Name="BuildAccelerationIncompatiblePackage" | ||
| xmlns="http://schemas.microsoft.com/build/2009/properties"> | ||
|
|
||
| <Rule.DataSource> | ||
| <DataSource HasConfigurationCondition="False" | ||
| MSBuildTarget="CollectBuildAccelerationIncompatiblePackageDesignTime" | ||
| Persistence="ProjectFile" | ||
| SourceOfDefaultValue="AfterContext" | ||
| SourceType="TargetResults" /> | ||
| </Rule.DataSource> | ||
|
|
||
| </Rule> |
There was a problem hiding this comment.
We don't need any properties for these items — just the item spec.
| private bool? _isBuildAccelerationEnabled; | ||
| private bool? _isBuildAccelerationEnabledInProject; |
There was a problem hiding this comment.
I renamed this, which increased the diff size here unfortunately. But the field no longer specified whether BA is enabled, only whether the AccelerateBuildsInVisualStudio property is present and with what value. We have added other ways of controlling whether BA is enabled (feature flag and incompatible package references) so the old name became misleading.
| @@ -39,7 +39,8 @@ public sealed class BuildUpToDateCheckTests : BuildUpToDateCheckTestBase, IDispo | |||
| private bool _isTaskQueueEmpty = true; | |||
| private bool _isFastUpToDateCheckEnabledInSettings = true; | |||
| private bool _isBuildAccelerationEnabledInSettings; | |||
| private bool? _isBuildAccelerationEnabled; | |||
| private bool? _isBuildAccelerationEnabledInProject; | |||
| private bool? _expectedIsBuildAccelerationEnabled; | |||
There was a problem hiding this comment.
I added this new field. Where we used to use _isBuildAccelerationEnabled to indicate whether we expected BA to ultimately be considered as enabled, we now need to take into account other inputs (as mentioned in my prior comment). This makes that explicit on the expectation side.
Contributes to #9106
While rare, it's possible for a NuGet package to include
.propsand/or.targetsfiles that customise the build in a way that's not compatible with Build Acceleration. Ideally such packages would also setAccelerateBuildsInVisualStudiotofalse, however that's not always an option.To address this situation, this change introduces the ability to specify NuGet packages that, when present in a project, will disable Build Acceleration.
We add one known package (
Microsoft.VSSDK.BuildTools, for VSIX projects) to our design-time.targetsfile, but SDKs and customers may add their own items too.For example, if
MyPackageis known to be incompatible with Build Acceleration, adding aBuildAccelerationIncompatiblePackageitem to yourDirectory.Build.propswill automatically cause Build Acceleration to be disabled for any project that references thatMyPackage:When a project is found to have an incompatible project reference, the FUTDC log displays a message to that effect, such as:
Microsoft Reviewers: Open in CodeFlow