You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
I think that arcade should provide this functionality to repos in the core stack. The shape of this functionality should be:
Known*
items updated or added automaticallyUpdate
to the latest runtime versionKnown*
version should be added to support the new TFM.Unified Build makes this functionality more important because the TFM update tends to need to be done simultaneously across the core shared framework repos.
The text was updated successfully, but these errors were encountered: