azure-sdk-for-net
azure-sdk-for-net copied to clipboard
ClientModel: Migrate stable types from Azure.Core Shared source to public types
Library name
Azure.Core
Types
- [ ] ClientDiagnostics (allows removal of reflection in DiagnosticsScope.
- [ ] Files in azure-sdk-for-net/sdk/core/Azure.Core/src/Shared
Note: shared source in the autorest.csharp repo is now tracked by https://github.com/Azure/azure-sdk-for-net/issues/32006
Includes migrating Generator Shared source to Azure.Core public types as well.
Related to:
- https://github.com/Azure/autorest.csharp/issues/2231
- https://github.com/Azure/autorest.csharp/issues/2148
In the Zinc timeframe, we plan to make a plan for this migration.
Related to https://github.com/Azure/azure-sdk-for-net/issues/30714
As @christothes brought up in triage, perhaps this could be broken up into bite-sized issues - some of which could be done in MQ potentially.
Specific customer ask for MultipartFormDataContent to be made public in https://github.com/Azure/azure-sdk-for-net/issues/24819
Consolidating types that standardize exceptions to a single type could address the following files:
- Argument.cs
- ModelSerializerHelper.cs
- OperationHelper.cs
- CancellationHelper.cs
We have had a few issues where we have considered having Helper\Utility APIs that may be useful to other SDKs and we should consider exposing those APIs are public helper methods in core.
We have had a few issues where we have considered having Helper\Utility APIs that may be useful to other SDKs and we should consider exposing those APIs are public helper methods in core.
@pallavit, would it be possible to link those issues to this one so we can track them together?
Why is this a P1? For instance, why supporting this is higher priority than enabling support for pagination in debranded toolchain?
Why is this a P1? For instance, why supporting this is higher priority than enabling support for pagination in debranded toolchain?
My initial impression is that for our efforts to parallelize Core work, it'd be good to have a plan here to unblock forward progress as we chip away on these types. For pagination, I don't know of a concrete scenario, but I'm open to reprioritization based on new information, so please view what we have today as the start of the conversation and happy to reshuffle as needed!
TODO: consider adding a helper to polyfill missing APIs on netstandard2.0 in serialization routines, e.g. to use one type for instances of https://github.com/search?q=repo%3AAzure%2Fazure-sdk-for-net+NET6_0_OR_GREATER+NOT+path%3AResourceManager&type=code&p=3
Hi @christothes, we deeply appreciate your input into this project. Regrettably, this issue has remained inactive for over 2 years, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.
Issue still active and slated for this semester
Issue still active and slated for this semester
After 30 days of no activity, the bot will close this again. I'm going to clone the issue in order to buy us two more years of peace.
New issue: # #43760