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

Formalize Known*Pack and Known*Reference support in Arcade #15121

Open
mmitche opened this issue Oct 1, 2024 · 1 comment
Open

Formalize Known*Pack and Known*Reference support in Arcade #15121

mmitche opened this issue Oct 1, 2024 · 1 comment

Comments

@mmitche
Copy link
Member

mmitche commented Oct 1, 2024

Repositories in the core stack of .NET either get their runtime packs, targeting packs, crossgen tooling, etc. from the SDK, or from an incoming runtime build. In some cases, it may be a bit of a hybrid. For instance, windowsdesktop might get its targeting pack from the incoming runtime, but the crossgen tooling from the SDK. To achieve this, repositories use KnownFrameworkReference and other items to update or add the version of the pack to the SDK's known list.

The problem is that use of these properties is relatively inconsistent across the stack, and when it comes time to update to a new TFM where an SDK for that TFM does not yet exist, things get awkward. Teams often have to put in temporary workarounds:

  • They may have been relying on the SDK for the TFM and need to add KnownFrameworkReference.
  • They may have been updating the KnownFrameworkReference, and it is now necessary to add a new KnownFrameworkReference for a TFM
  • They may obtain some functionality from the SDK and need additional workarounds to obtain crossgen2 packs.

I think that arcade should provide this functionality to repos in the core stack. The shape of this functionality should be:

  • If you depend on runtime and are in the core stack, a repo should be able to opt into have their Known* items updated or added automatically
  • If targeting a TFM that is available in the SDK, all items (ILC, crossgen, targeting pack) should have an appropriate Update to the latest runtime version
  • If targeting a TFM that is not available in the SDK, an additional Known* version should be added to support the new TFM.
  • If a repo is in the core stack and opting in to this functionality, it should not end up in a hybrid state where some runtime tooling comes from the SDK and some from the incoming runtime version.
  • A repo in the core stack should not have to opt in to this functionality in servicing.

Unified Build makes this functionality more important because the TFM update tends to need to be done simultaneously across the core shared framework repos.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Ready
Development

No branches or pull requests

2 participants