Developers using the Azure SDK on modern versions of .NET are required to download unnecessary packages that serve as polyfills for the legacy .NET framework and unsupported versions of .NET Core.
Developers are faced with longer build times, increased application size, and unnecessary network use.
This document attempts to define the set of rules used for triaging and managing issues in the Azure SDK for .NET repository. These rules were once part of a standardized process owned by Alex Ghiondea and were at least loosely followed in the other language repositories. It is unknown whether there has been drift in the processes between languages since.
At one point, these were documented in OneNote and then moved to a DevOps wiki, and then moved again. I do not know where the documentation exists today - if it still does. All that I'm aware of is a high-level view of the process.
The general form of settings stored in AppConfiguration are simple key/value string pairs, where both have no formal structure. AppConfiguration also has the notion of "feature flag" and "secret reference" configuration settings, which are loosely structured data, conforming to a minimal and extensible JSON schema. These settings are expected to include all elements from the JSON schema but are also permitted to include additional data in the form of simple or complex elements.
| // Package Reference: Azure.Data.AppConfiguration | |
| // Package Reference: System.Text.Json | |
| using Azure; | |
| using Azure.Core; | |
| using Azure.Core.Pipeline; | |
| using Azure.Data.AppConfiguration; | |
| using System.Threading.Tasks; | |
| using System.Text.Json; | |
| using System.Text.Json.Serialization; |
Azure Schema Registry currently supports the Avro schema type and is adding support for JSON Schema. The Azure SDK library for Schema Registry offers an Avro serializer that is integrated with the Schema Registry client. In order to provide parity between the schema formats, serializer support for JSON Schema with a developer experience consistent with Avro is needed.
Contributes to the Kafka/Confluent compete story for Event Hubs. (marketing "checkbox" feature)
Contributes to the Kafka interoperability story for Event Hubs, focusing on cross-product producing and consuming scenarios. (marketing "checkbox" feature)
Enables a consistent developer experience with Schema Registry across different schema formats, reducing support costs and special-case documentation needs.
This document attempts to define a set of logical rules based on the existing Fabric Bot implementation. Rules are described based on their logical association; in some cases, these may need to be expanded into multiple physical rules due to how GitHub events and/or Actions work. Likewise, concepts and flow are intentionally kept abstract and do not intend to describe a specific implementation. An example of this is the different data integrations. Multiple data items may drive from a single source, but they constitute different logical concepts.
| private static BufferListStream Serialize(AmqpMessage message, int bufferSizeBytes = 4096) | |
| { | |
| var buffers = new List<ArraySegment<byte>>(); | |
| var more = true; | |
| while (more) | |
| { | |
| var messageBuffers = message.GetPayload(bufferSizeBytes, out more); | |
| if (messageBuffers != null) |
| // This is the convenience layer that customers interact with. | |
| // This should look almost exactly like the current API: | |
| // https://apiview.dev/Assemblies/Review/2d2a87eaa70a43b8860f1c4e7135494b | |
| // | |
| // Because it isn't interacting with the swagger types, we probably need to clone the | |
| // current implementation and use it as template. | |
| // | |
| public class TextAnalyticsClient | |
| { | |
| TransportClient _transport = this.serviceVersion switch |
Currently the TextAnalytics client offers a set of bespoke methods for each operation that developers may wish to perform. These methods are associated with the operation by name, intending to allow operations to be discoverable when browsing code completion lists and organizing related methods into groups.
This pattern has worked well with the Text Analytics REST API, which offered roughly seven core analysis skills. As Text Analytics moves to the Unified Language API, it is expected that the number of skills offered will grow steadily. This growth may cause the number of bespoke methods to become burdensome for developers, necessitating an evolution of the client API.
Historically, Text Analytics has existed as a dedicated REST service in Azure, managed and evolved independently from other Cognitive Services offerings. This has led to developers working directly with the REST APIs having to learn unique locations, structure, and usage patterns for the different services, despite them having a similar goal of analyzing language-related aspects of documents.
Going forward, the Cognitive Services teams are consolidating REST APIs with related functionality into a single REST service. In the case of Text Analytics, service functionality is moving to a new unified language service. The API of the new unified language service introduces changes both structurally and behaviorally, making it incompatible with the API offered by the stand-alone Text Analytics REST service.
In order to support the unified language service, the client libraries will need to determine an approach able to accommodate the new REST API without in