Condition RestoreInternalTooling on OfficialBuild=true

[ViktorHofer]

To double check:

• The right tests are in and the right validation has happened. Guidance: https://github.com/dotnet/arcade/blob/main/Documentation/Validation.md

[mmitche]

This will work, but I'm not entirely sure it is correct (since a local dev could want to run these targets). The normal pattern for restoring internal tooling has been to have the target that requires the internal tooling depend on the internal tooling restore target (see _PrepareAcquireVisualStudioOptimizationData) rather than trying to predict whether it's necessary. Does this pattern not work in this case?

[ViktorHofer]

Unfortunately that doesn't work here.

1. arcade/src/Microsoft.DotNet.Arcade.Sdk/tools/AfterSigning.proj

   Line 50 in 4dc2518

   <Import Project="VisualStudio.InsertionManifests.targets" Condition="'$(UsingToolVSSDK)' == 'true' and '$(MSBuildRuntimeType)' != 'Core'" />

   imports VisualStudio.InsertionManifests.targets
2. The GenerateVisualStudioInsertionManifests target depends on internal tools. That target runs whenever desktop msbuild is used and the UsingToolVSSDK property is set to true (repos set that in their Versions.props i.e.).

That target in theory runs in public as well as AfterSigning.proj is always invoked:

arcade/src/Microsoft.DotNet.Arcade.Sdk/tools/Build.proj

Lines 287 to 290 in 4dc2518

	<MSBuild Projects="AfterSigning.proj"
	Properties="@(_CommonProps);_NETCORE_ENGINEERING_TELEMETRY=Sign"
	Targets="@(_SolutionBuildTargets)"
	Condition="'@(_SolutionBuildTargets)' != ''"/>

But back to your question, we can't depend on the RestoreInternalTooling target directly as AfterSigning.proj is in another project and we should only restore internal tools up-front and not after the build.

[ViktorHofer]

FWIW I think we should merge this PR in to fix the regression and then follow-up on a better design.

We might need an opt-in property for the GenerateVisualStudioInsertionManifests target.

[mmitche]

Sounds good