.NET Aspire Integrations Progress

These integrations should follow the .NET Aspire Integration Requirements. Below is a chart that shows the progress of each of the client integrations we ship, and their current stance against each of the requirements.

.NET Aspire Integration Name	Contains README	Public API	Configuration Schema	DI Services	Logging	Tracing	Metrics	Health Checks
Npgsql	✅	✅	✅	✅	✅	✅	✅	✅
Npgsql.EntityFrameworkCore.PostgreSQL	✅	✅	✅	✅	✅	✅	✅	✅
Microsoft.Azure.Cosmos	✅	✅	✅	✅	✅	✅	❌	❌
Microsoft.Data.SqlClient	✅	✅	✅	✅	❌	✅	❌	✅
Microsoft.EntityFramework.Cosmos	✅	✅	✅	✅	✅	✅	❌	❌
Microsoft.EntityFrameworkCore.SqlServer	✅	✅	✅	✅	✅	✅	❌	✅
Microsoft.Extensions.Configuration.AzureAppConfiguration	✅	✅	✅	✅	✅	✅	❌
MongoDB.Driver	✅	✅	✅	✅	✅	✅	❌	✅
Azure.AI.Inference	✅	✅	✅	✅	✅	✅	❌	❌
Azure.AI.OpenAI	✅	✅	✅	✅	✅	✅	✅	❌
Azure.Data.Tables	✅	✅	✅	✅	✅	✅	❌	✅
Azure.Messaging.EventHubs	✅	✅	✅	✅	✅	✅	❌
Azure.Messaging.WebPubSub	✅	✅	✅	✅	✅	✅	❌	✅
Azure.Messaging.ServiceBus	✅	✅	✅	✅	✅	✅	❌	✅
Azure.Npgsql	✅	✅	✅	✅	✅	✅	✅	✅
Azure.Npgsql.EntityFrameworkCore.PostgreSQL	✅	✅	✅	✅	✅	✅	✅	✅
Azure.Search.Documents	✅	✅	✅	✅	✅	✅	❌	✅
Azure.Security.KeyVault	✅	✅	✅	✅	✅	✅	❌	✅
Azure.Storage.Blobs	✅	✅	✅	✅	✅	✅	❌	✅
Azure.Storage.Queues	✅	✅	✅	✅	✅	✅	❌	✅
StackExchange.Redis	✅	✅	✅	✅	✅	✅	❌	✅
StackExchange.Redis.DistributedCaching	✅	✅	✅	✅	✅	✅	❌	✅
StackExchange.Redis.OutputCaching	✅	✅	✅	✅	✅	✅	❌	✅
RabbitMQ	✅	✅	✅	✅	✅		❌	✅
MySqlConnector	✅	✅	✅	✅	✅	✅	✅	✅
OpenAI	✅	✅	✅	✅	❌	✅	✅	❌
Oracle.EntityFrameworkCore	✅	✅	✅	✅	✅	✅	❌	✅
Confluent.Kafka	✅	✅	✅	✅	✅	❌	✅	✅
Pomelo.EntityFrameworkCore.MySql	✅	✅	✅	✅	✅	✅	✅	✅
NATS.Net	✅	✅	✅	✅	✅	✅		✅
Seq	✅	✅	✅	✅	✅	N/A	N/A	✅
Qdrant.Client	✅	✅	✅	✅	✅
Milvus.Client	✅	✅	✅	✅	✅			✅
Elastic.Clients.Elasticsearch	✅	✅	✅	✅		✅		✅

Nomenclature used in the table above:

• ✅ - Requirement is met
• (blank) - Requirement hasn't been met yet
• ❌ - Requirement can't be met
• N/A - Requirement not applicable

.NET Aspire Integration Requirements

Contains README

Each .NET Aspire integration must contain a README.md file which is included in the package. This README should contain the integration's main description, usage examples, and basic getting started documentation. The goal of this file is to contain everything a developer will need in the first 5 minutes. Finally, README should have a link pointed back to the full documentation of the integration, which will include a list of logging categories used, tracing activity names, and Metric names. Here's a concrete example of a README file.

Public API

Each integration must go through an API Review that will validate that the API shape proposed by the integration is conforming to the guidelines. This also includes the naming conventions.

Json Schema/Configuration

Each integration should provide a sealed Settings type as well as named configuration which will showcase the exposed settings for that specific integration. This will also include the Logging section in which categories are listed and can be configured. For more information, please check out the configuration best practices

DI Services

Integrations must have extension methods which will "glue" the services with the DI container. For an example of this, please check out the AspireRedisExtensions class here. The extension methods that are registering the main integration's service to the container should be listed in the README file. The full list of registered services by the integration should be included in the main integration's documentation page.

Health Checks

Aspire integrations should expose health checks enabling applications to track and respond to the remote service’s health. For more information, please check out the health checks best practices.

Telemetry

Logging

Integrations should produce Logs as part of them being cloud-ready. As part of the integration's main documentation, it's a requirement to list out the different categories that it uses for logging. The list of categories doesn't need to be exhaustive, but it should include at least the logical level groupings used.

Tracing

Integrations should also produce tracing information as part of them being cloud-ready. As part of the integration's main documentation, it's a requirement to list out the different activity names that it uses for tracing. It is not a requirement to include tag names.

Metrics

Integrations should also produce metrics as part of them being cloud-ready. As part of the integration's main documentation, it's a requirement to list out the different metric names that it uses. It is not a requirement to also include dimensions.