Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix fast up to date check with ServiceHub projects #77038

Conversation

jasonmalinowski
Copy link
Member

@jasonmalinowski jasonmalinowski commented Feb 4, 2025

This fixes the fast-up-to-date check with ServiceHub projects. High level there were a few problems:

  1. The arcade targets try to provide up-to-date check items, but we're consuming older targets with some issues. This copies in the version which is in the VS SDK itself so we can deprecate the Arcade versions.
  2. The ServiceHub setup projects consume the published output of other projects, but won't necessarily trigger the publish itself. This can mean the setup projects are considered "up to date" even if a publish would produce new binaries.

You will see overbuilding with this change due to #77039.

This hacks around the fact that the Arcade bits we're currently picking
up are older and don't correctly define the VSIX up-to-date checks
needed. This overrides those targets and copies in the bits we're
going to consume from the VS SDK directly.
@jasonmalinowski jasonmalinowski requested review from a team as code owners February 4, 2025 22:45
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Infrastructure untriaged Issues and PRs which have not yet been triaged by a lead labels Feb 4, 2025
Without this change, it's possible to make a change in the regular
product but not get ServiceHub to rebuild. This is because the output
group we consume in the VSIX consumes the published output (by
necessity) but doesn't trigger the publish itself. The publish is
triggered by the PublishProjectReferencesForVsixCreation in the same
file prior to the VSIX build. But if the fast-up-to-date check sees
the project as up to date (because no publish happened), then we'll
never actually run the publish in the first place.

The solution here is to add items that get published to the list of
VSIX inputs, so that way we'll trigger the full build (and publish)
correctly.
<Project>

<!-- The 9.0 Arcade targets we are consuming don't have Sets specified for the items, and don't include all items correctly. This overrides
those targets so they don't interfere. These two empty targets can be deleted when we've removed the support from Arcade in favor of
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what exactly needs to happen for this? Do we need to switch to arcade's 10 channel and update our VSSDK to some version?

Or are we planning on backporting the change to the arcade 9 channel along with the VSSDK fix?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My plan:

  1. The VS SDK will take the proper fixes into their SDK, and we'll update to it. We'll delete our copies here.
  2. We'll delete the targets entirely from the 10.0 arcade channel, and once we update to arcade 10.0 we'll remove the overrides here.

The main goal then being the VS SDK is doing the thing it should be doing, and we don't have multiple places trying to fight at once.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My assumption here is we'll be moving to 10.0 arcade soonish.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe we can only move once there is a public preview download for .net 10. Not 100% sure what the date on that is.

<Project>

<!-- The 9.0 Arcade targets we are consuming don't have Sets specified for the items, and don't include all items correctly. This overrides
those targets so they don't interfere. These two empty targets can be deleted when we've removed the support from Arcade in favor of
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you link to the version of these targets we are currently referencing?

Copy link
Member Author

@jasonmalinowski jasonmalinowski Feb 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's this version:

https://github.com/dotnet/arcade/blob/bac7e1caea791275b7c3ccb4cb75fd6a04a26618/src/Microsoft.DotNet.Arcade.Sdk/tools/VisualStudio.VsixBuild.targets#L288-L310

I guess I could revise the comment, but fundamentally those need to be using the Set attribute or otherwise you end up with other issues. And the newer Arcade targets (and also the VS SDK targets if were consuming it via the SDK syntax) do that correctly.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the 'Set' attribute?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jasonmalinowski jasonmalinowski merged commit 9919bb9 into dotnet:main Feb 5, 2025
28 checks passed
@jasonmalinowski jasonmalinowski deleted the fix-fast-up-to-date-check-with-servicehub-projects branch February 5, 2025 01:10
@dotnet-policy-service dotnet-policy-service bot added this to the Next milestone Feb 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Infrastructure untriaged Issues and PRs which have not yet been triaged by a lead
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants