Novità di .NET.NET Aspire 9.0
📢 .NET Aspire 9.0 è la prossima versione di disponibilità generale principale di .NET Aspire; supporta entrambi i:
- .NET 8.0 Supporto a Lungo Termine (LTS) o
- .NET 9.0 Standard Term Support (STS).
Nota
È possibile usare .NET Aspire 9.0 con .NET 8 o .NET 9!
Questa versione risolve alcune delle funzionalità e dei punti deboli più richiesti dalla community. Le migliori funzionalità sono guidate dalla community. Per partecipare alla community, visitaci su 
Discord per chattare con i membri del team e collaborare con noi su 
GitHub.
Per altre informazioni sulla versione ufficiale .NET e sul supporto della versione .NET Aspire, vedere:
- .NET Politica di supporto: definizioni per LTS e STS.
- .NET .NET Aspire politica di supporto: importanti dettagli univoci del ciclo di vita del prodotto.
Eseguire l'aggiornamento a .NET.NET Aspire 9
Per eseguire l'aggiornamento da versioni precedenti di .NET Aspire a .NET Aspire 9, seguire le istruzioni riportate nella guida ufficiale Upgrade to .NET.NET Aspire 9. La guida fornisce istruzioni dettagliate su come aggiornare le soluzioni di .NET Aspire esistenti a .NET Aspire 9. Che tu stia eseguendo manualmente o utilizzando l'Assistente per l'aggiornamento, la guida rende il processo rapido.
Miglioramenti degli strumenti
.NET Aspire 9 semplifica la configurazione dell'ambiente per lo sviluppo di applicazioni .NET Aspire. Non è più necessario un carico di lavoro .NET. Invece, installa il nuovo SDK .NET.NET Aspire nel progetto host dell'app delle soluzioni .NET.NET Aspire. Per altre informazioni, vedere .NET.NET Aspire configurazione e strumenti.
I modelli sono stati spostati
.NET
.NET Aspire 9 sta spostando i contenuti che erano precedentemente installati tramite il workload in pacchetti NuGet separati. Sono inclusi i modelli per la creazione di nuovi progetti e soluzioni .NET.NET Aspire. Questi modelli vengono installati usando il comando dotnet new install. Questi possono essere installati eseguendo il comando seguente:
dotnet new install Aspire.ProjectTemplates::9.0.0
Consiglio
Se hai già installato il workload .NET.NET Aspire, devi passare il flag --force per sovrascrivere i modelli esistenti. Se lo desideri, puoi disinstallare il carico di lavoro .NET.NET Aspire.
Per altre informazioni, vedere i template .NET.NET Aspire.
Miglioramenti dell'esperienza utente del dashboard e nuove funzionalità di interattività
Il dashboard .NET.NET Aspire continua a migliorare con ogni versione.
Gestire il ciclo di vita delle risorse
La funzionalità più richiesta per il dashboard consiste nel gestire i cicli di vita delle risorse denominate orchestrate. In particolare, la possibilità di arrestare, avviare e riavviare le risorse. Questa funzionalità funziona per progetti, contenitori ed eseguibili. Consente di riavviare singole risorse senza dover riavviare l'intero host dell'app. Per le risorse del progetto, quando il debugger è collegato, viene nuovamente collegato al riavvio. Per ulteriori informazioni, vedere la dashboard .NET.NET Aspire: Interrompere o avviare una risorsa.
Supporto mobile e reattivo
Il dashboard .NET Aspire è ora compatibile con dispositivi mobili, adattandosi in modo reattivo a un'ampia gamma di dimensioni dello schermo e abilitando la gestione on-the-go delle applicazioni .NET Aspire distribuite. Sono stati apportati altri miglioramenti all'accessibilità, tra cui la visualizzazione delle impostazioni e la gestione del trabocco dei contenuti sui dispositivi mobili.
Proprietà sensibili, volumi e verifiche di integrità nei dettagli delle risorse
La visualizzazione dei dettagli delle risorse contiene diversi miglioramenti:
Le proprietà possono essere contrassegnate come sensibili, mascherandole automaticamente nell'interfaccia utente del dashboard. Questa funzionalità di sicurezza consente di evitare di divulgare accidentalmente chiavi o password durante la condivisione dello schermo del dashboard con altre persone. Ad esempio, gli argomenti del contenitore possono trasmettere informazioni riservate e per impostazione predefinita sono quindi mascherati.
I volumi di contenitori configurati sono elencati nei dettagli delle risorse.
.NET .NET Aspire 9 aggiunge il supporto per i controlli di integrità. Le informazioni dettagliate su questi controlli possono ora essere visualizzate nel riquadro dei dettagli della risorsa, che illustrano il motivo per cui una risorsa potrebbe essere contrassegnata come non integra o danneggiata. Scopri di più sui check-up della salute qui.
Log della console a colori
codici di escape ANSI formattare il testo nei terminali controllando colori (primo piano e sfondo) e stili come grassetto, sottolineatura e corsivo. In precedenza, la pagina dei log della console del dashboard poteva eseguire il rendering di un solo codice di escape ANSI alla volta, con esito negativo quando sono stati combinati più codici. Ad esempio, potrebbe visualizzare testo rosso, ma non testo sia rosso che grassetto.
Un contributo della community di @mangeg ha migliorato il supporto per i codici di escape ANSI e ha rimosso questa limitazione.
Un altro miglioramento dei log della console è nascondere i codici di escape non supportati. I codici non correlati alla visualizzazione del testo, ad esempio il posizionamento del cursore o la comunicazione con il sistema operativo non hanno senso in questa interfaccia utente e sono nascosti.
Aggiunte di telemetria incentrate sugli utenti
Telemetria rimane un aspetto essenziale di .NET.NET Aspire. In .NET.NET Aspire 9 sono state introdotte molte nuove funzionalità nel servizio telemetria.
Filtro dei dati di telemetria migliorato
Le tracce possono essere filtrate con valori di attributo. Ad esempio, se vuoi visualizzare solo le tracce per un endpoint nell'app, l'attributo http.route nelle richieste HTTP può essere filtrato in base a un valore specificato.
Il filtro dei dati di telemetria supporta anche il completamento automatico dei valori esistenti. Nella finestra di dialogo Aggiungi filtro è disponibile una casella combinata per selezionare tra i valori che il dashboard ha disponibili. Questa funzionalità semplifica notevolmente il filtro dei dati reali e consente di evitare errori di digitazioni immettendo manualmente un valore.
Per ulteriori informazioni, consultare il dashboard .NET.NET Aspire: Filtro delle tracce.
Combinare i dati di telemetria da più risorse
Quando una risorsa ha più repliche, è ora possibile filtrare i dati di telemetria per visualizzare i dati di tutte le istanze contemporaneamente. Selezionare la risorsa padre, etichettata (application). Per altre informazioni, vedere dashboard .NET.NET Aspire: Combinare i dati di telemetria da più risorse.
Supporto alla telemetria del browser
Il dashboard supporta il protocollo OpenTelemetry (OTLP) tramite HTTP e la condivisione di risorse tra le origini (CORS). Queste funzionalità consentono di inviare OpenTelemetry dalle app del browser al dashboard di .NET Aspire.
Ad esempio, un'app a pagina singola basata su browser può configurare la OpenTelemetry JavaScript SDK per inviare log strutturati, tracce e metriche create nel browser al dashboard. I dati di telemetria del browser vengono visualizzati insieme ai dati di telemetria del server.
Per altre informazioni sulla configurazione dei dati di telemetria del browser, vedere Abilitare la telemetria del browser documentazione.
Host dell'app (orchestrazione)
L'host dell'app
In attesa di dipendenze
Se hai seguito .NET.NET Aspire, già sai che il progetto host della tua app è il punto dove definisci il modello della tua app. Creare un generatore di applicazioni distribuite, aggiungere e configurare risorse ed esprimere le relative dipendenze. A questo punto, è possibile specificare che una risorsa deve attendere finché un'altra risorsa non è disponibile prima di iniziare. Ciò consente di evitare errori di connessione durante l'avvio avviando le risorse solo quando le relative dipendenze sono "pronte".
var builder = DistributedApplication.CreateBuilder(args);
var rabbit = builder.AddRabbitMQ("rabbit");
builder.AddProject<Projects.WebApplication1>("api")
.WithReference(rabbit)
.WaitFor(rabbit); // Don't start "api" until "rabbit" is ready...
builder.Build().Run();
All'avvio dell'host dell'app, attende che la risorsa rabbit sia pronta prima di avviare la risorsa api.
Esistono due metodi disponibili per attendere una risorsa:
- WaitFor: attendere che una risorsa sia pronta prima di avviare un'altra risorsa.
- WaitForCompletion: attendere il completamento di una risorsa prima di avviare un'altra risorsa.
Per ulteriori informazioni, vedere: host dell'app .NET.NET Aspire In attesa di risorse.
Controlli di integrità delle risorse
L'API WaitFor usa controlli di integrità standard .NET per determinare se una risorsa è pronta. Ma cosa significa "una risorsa pronta"? La parte migliore è che sia configurabile dal consumatore per valori diversi dai predefiniti.
Quando una risorsa non espone alcun controllo di integrità (nessun controllo di integrità registrato nell'app), l'host dell'app attende che la risorsa sia nello stato Running prima di avviare la risorsa dipendente.
Per le risorse che espongono endpoint HTTP, puoi facilmente aggiungere un controllo di integrità che esegue il polling di un percorso specifico per ottenere una risposta HTTP 200.
var builder = DistributedApplication.CreateBuilder(args);
var catalogApi = builder.AddContainer("catalog-api", "catalog-api")
.WithHttpEndpoint(targetPort: 8080)
.WithHttpHealthCheck("/health");
builder.AddProject<Projects.WebApplication1>("store")
.WithReference(catalogApi.GetEndpoint("http"))
.WaitFor(catalogApi);
builder.Build().Run();
Nell'esempio precedente viene aggiunto un controllo di integrità alla risorsa catalog-api. L'host dell'app attende che la verifica di integrità restituisca uno stato di integrità prima di avviare la risorsa store. Determina che la risorsa è pronta quando l'endpoint /health restituisce un codice di stato HTTP 200.
Mentre store è in attesa che catalog-api diventi integro, le risorse nel dashboard vengono visualizzate come:
Il meccanismo di controllo dell'integrità dell'app host si basa sull'implementazione IHealthChecksBuilder nel namespace Microsoft.Extensions.Diagnostics.HealthChecks.
Dati del report dei controlli sanitari, visualizzati nel pannello di controllo:
La creazione di una verifica di integrità personalizzata è semplice. Per iniziare, definire il controllo integrità, quindi associarne il nome a tutte le risorse a cui si applica.
var builder = DistributedApplication.CreateBuilder(args);
var healthyAfter = DateTime.Now.AddSeconds(20);
builder.Services.AddHealthChecks().AddCheck(
"delay20secs",
() => DateTime.Now > healthyAfter
? HealthCheckResult.Healthy()
: HealthCheckResult.Unhealthy()
);
var cache = builder.AddRedis("cache")
.WithHealthCheck("delay20secs");
builder.AddProject<Projects.MyApp>("myapp")
.WithReference(cache)
.WaitFor(cache);
L'esempio precedente aggiunge un controllo di integrità alla risorsa cache, segnalando quest'ultima come non sana per i primi 20 secondi dopo l'avvio dell'host dell'app. Pertanto, la risorsa myapp attende 20 secondi prima di iniziare, assicurando che la risorsa cache sia funzionante correttamente.
I metodi AddCheck e WithHealthCheck forniscono un semplice meccanismo per creare controlli di integrità e associarli a risorse specifiche.
Contenitori persistenti
L'host dell'app supporta ora contenitori permanenti di . I contenitori persistenti si discostono dal ciclo di vita tipico dei contenitori di .NET.NET Aspire app orchestrate. Anche se vengono creati e avviato (quando non è già disponibile) dall'agente di orchestrazione .NET Aspire, non vengono eliminati definitivamente da .NET Aspire.
Ciò è utile quando si vuole mantenere il contenitore in esecuzione anche dopo l'arresto dell'host dell'app.
Importante
Per eliminare questi contenitori, è necessario arrestarli manualmente usando il runtime del contenitore.
Per definire un IResourceBuilder<ContainerResource> con una durata persistente, chiamare il metodo WithLifetime e passare ContainerLifetime.Persistent:
var builder = DistributedApplication.CreateBuilder(args);
var queue = builder.AddRabbitMQ("rabbit")
.WithLifetime(ContainerLifetime.Persistent);
builder.AddProject<Projects.WebApplication1>("api")
.WithReference(queue)
.WaitFor(queue);
builder.Build().Run();
Il dashboard mostra i contenitori permanenti con un'icona a forma di puntina:
Dopo l'arresto dell'host dell'app, il contenitore continuerà a funzionare.
Il meccanismo di persistenza del contenitore tenta di identificare quando si potrebbe voler ricreare il contenitore. Ad esempio, se l'ambiente per il contenitore cambia, il contenitore viene riavviato in modo che non sia necessario arrestare manualmente il contenitore se la configurazione di input per la risorsa è cambiata.
Comandi delle risorse
L'host dell'app supporta l'aggiunta di comandi personalizzati alle risorse. Ciò è utile quando vuoi aggiungere funzionalità personalizzate non supportate in modo nativo dall'host dell'app. È probabile che vi siano molte opportunità in cui esporre metodi di estensione personalizzati sulle risorse sarà utile. Il .NET.NET Aspire Community Toolkit potrebbe essere un buon posto per condividere queste estensioni.
Quando si definisce un comando personalizzato, è disponibile nel dashboard come funzionalità dell'esperienza utente.
Importante
Questi comandi della dashboard .NET.NET Aspire sono disponibili solo quando si esegue la dashboard localmente. Non sono disponibili quando si esegue il dashboard in Azure Container Apps.
Per altre informazioni sulla creazione di comandi di risorse personalizzati, vedere Procedura: Creare comandi di risorse personalizzate in .NET.NET Aspire.
Rete dei contenitori
L'host dell'app aggiunge ora tutti i contenitori a una rete comune denominata default-aspire-network. Ciò è utile quando si vuole comunicare tra contenitori senza passare attraverso la rete host. In questo modo è anche più semplice eseguire la migrazione da docker compose all'host dell'app, in quanto i contenitori possono comunicare tra loro usando il nome del contenitore.
Modello di gestione eventi
Il modello di eventi consente agli sviluppatori di integrare il ciclo di vita dell'applicazione e delle risorse. Ciò è utile per l'esecuzione di codice personalizzato in punti specifici del ciclo di vita dell'applicazione. Esistono diversi modi per sottoscrivere eventi, inclusi eventi globali ed eventi per risorsa.
Eventi globali:
- BeforeStartEvent: evento attivato prima dell'avvio dell'applicazione. Questa è l'ultima posizione in cui vengono osservate le modifiche apportate al modello di app. Questa operazione viene eseguita in modalità "Esegui" e "Pubblica". Si tratta di un evento di blocco, vale a dire che l'applicazione non viene avviata fino a che tutti gli handler siano completati.
- AfterResourcesCreatedEvent: evento attivato dopo la creazione delle risorse. Questa funzione viene eseguita solo in modalità Run.
- AfterEndpointsAllocatedEvent: evento attivato dopo l'allocazione degli endpoint per tutte le risorse. Questa funzione viene eseguita solo in modalità Run.
Gli eventi globali sono analoghi agli eventi del ciclo di vita dell'host dell'app. Per altre informazioni, vedere ciclo di vita dell'host dell'app .
eventi per risorsa:
- BeforeResourceStartedEvent: evento attivato prima dell'avvio di una singola risorsa. Questa funzione viene eseguita solo in modalità Run. Si tratta di un evento di blocco, ovvero la risorsa non viene avviata fino al completamento di tutti i gestori.
- ConnectionStringAvailableEvent: evento che viene attivato quando una stringa di connessione è disponibile per una risorsa. Questa funzione viene eseguita solo in modalità Run.
- ResourceReadyEvent: evento che viene attivato quando una risorsa è pronta per l'uso. Questa funzione viene eseguita solo in modalità Run.
Per altre informazioni, vedere Eventing in .NET.NET Aspire.
Integrazioni
.NET .NET Aspire continua ad aggiungere integrazioni che semplificano l'introduzione ai servizi e agli strumenti preferiti. Per altre informazioni, vedere panoramica delle integrazioni .NET.NET Aspire.
Redis Informazioni dettagliate
Il supporto per Redis Insights è disponibile in una risorsa Redis:
var builder = DistributedApplication.CreateBuilder(args);
builder.AddRedis("redis")
.WithRedisInsight(); // Starts a Redis Insight container image
// that is pre-configured to work with the
// Redis instance.
Il metodo di estensione WithRedisInsight può essere applicato a più risorse Redis e ognuna sarà visibile nel dashboard di Redis Insight.
.
Per ulteriori informazioni, vedere Aggiungi risorsa Redis con Redis Insights.
OpenAI (anteprima)
A partire da .NET Aspire 9, è disponibile un'integrazione aggiuntiva OpenAI che consente di usare direttamente la libreria dotnet ufficiale più recente OpenAI. L'integrazione client registra il OpenAIClient come servizio singleton nella raccolta di servizi. Il client può essere usato per interagire con l'API OpenAIREST.
- 📦 Aspire.OpenAI (anteprima)
Inoltre, l'integrazione .NET AspireAzureOpenAI già disponibile è stata migliorata per offrire un modo flessibile per configurare un OpenAIClient per un servizio Azure AI OpenAI o un'API OpenAIREST dedicata con il nuovo metodo builder di AddOpenAIClientFromConfiguration(IHostApplicationBuilder, String). Nell'esempio seguente viene rilevato se la stringa di connessione è per un servizio AzureAzure AI OpenAI e registra automaticamente l'istanza di OpenAIClient più appropriata.
builder.AddOpenAIClientFromConfiguration("openai");
Ad esempio, se la connessione openai ha un aspetto simile a Endpoint=https://{account}.azure.com;Key={key}; potrebbe indovinare che può registrare un client AzureAzure AI OpenAI a causa del nome di dominio. In caso contrario, verrebbe usata una OpenAIClient comune.
Per ulteriori dettagli, leggere la risoluzione compatibile con qualsiasi client Azure.
MongoDB
Aggiunto supporto per specificare il nome utente e la password MongoDB quando si usa il metodo di estensione AddMongoDB(IDistributedApplicationBuilder, String, Nullable<Int32>, IResourceBuilder<ParameterResource>, IResourceBuilder<ParameterResource>). Se non specificato, viene generato un nome utente e una password casuali, ma è possibile specificare manualmente usando le risorse dei parametri.
var builder = DistributedApplication.CreateBuilder(args);
var username = builder.AddParameter("mongousername");
var password = builder.AddParameter("mongopassword", secret: true);
var db = builder.AddMongo("db", username, password);
Importanti miglioramenti Azure
Le sezioni seguenti descrivono i miglioramenti Azure apportati in .NET Aspire 9. Per un elenco completo di tutte le modifiche che rompono la compatibilità, vedere nel capitolo Modifiche in .NET.NET Aspire 9.
Azure personalizzazione delle risorse
In .NET Aspire 8, la personalizzazione delle risorse Azure è stata contrassegnata come sperimentale perché le librerie Azure.Provisioning sottostanti erano nuove e raccoglievano feedback prima che potessero essere contrassegnate come stabili. In .NET.NET Aspire 9 queste API sono state aggiornate e l'attributo sperimentale è stato rimosso.
Azure modifica che causa un'interruzione della denominazione delle risorse
Nell'ambito dell'aggiornamento alle librerie di Azure.Provisioning, lo schema di denominazione predefinito per le risorse Azure è stato aggiornato con un supporto migliore per vari criteri di denominazione. Tuttavia, questo aggiornamento ha comportato una modifica alla modalità di chiamata delle risorse. I nuovi criteri di denominazione potrebbero comportare l'abbandono delle risorse Azure esistenti e la creazione di nuove risorse Azure dopo l'aggiornamento dell'applicazione .NET Aspire da 8 a 9. Per continuare a usare gli stessi criteri di denominazione da .NET.NET Aspire 8, è possibile aggiungere il codice seguente all'Program.csAppHost :
var builder = DistributedApplication.CreateBuilder(args);
builder.Services.Configure<AzureProvisioningOptions>(options =>
{
options.ProvisioningBuildOptions.InfrastructureResolvers.Insert(0, new AspireV8ResourceNamePropertyResolver());
});
Azure SQL, PostgreSQLe Redis Aggiornamento
Azure risorse SQL, PostgreSQLe Redis sono diverse da altre risorse di Azure perché queste tecnologie dispongono di risorse di contenitore locali. In .NET Aspire 8, per poter creare queste risorse Azure, dovevi cominciare con una risorsa contenitore locale e poi "As" o "PublishAs" verso una risorsa Azure. Questa progettazione ha introdotto problemi e non è adattata ad altre API.
Ad esempio, è possibile avere questo codice in .NET.NET Aspire 8:
var builder = DistributedApplication.CreateBuilder(args);
var sql = builder.AddSqlServer("sql")
.PublishAsAzureSqlDatabase();
var pgsql = builder.AddPostgres("pgsql")
.PublishAsAzurePostgresFlexibleServer();
var cache = builder.AddRedis("cache")
.PublishAsAzureSqlDatabase();
In .NET.NET Aspire 9 queste API sono state contrassegnate come obsolete e un nuovo modello di API implementato:
var builder = DistributedApplication.CreateBuilder(args);
var sql = builder.AddAzureSqlServer("sql")
.RunAsContainer();
var pgsql = builder.AddAzurePostgresFlexibleServer("pgsql")
.RunAsContainer();
var cache = builder.AddAzureRedis("cache")
.RunAsContainer();
ID Microsoft Entra per impostazione predefinita
Per rendere più sicure le applicazioni .NET Aspire, il Azure Database relativo a PostgreSQL e alle risorse di Azure Cache for Redis è stato aggiornato all'uso dell'ID Microsoft Entra come predefinito. Ciò richiede modifiche alle applicazioni che devono connettersi a queste risorse. Per l'aggiornamento delle applicazioni per l'uso di Microsoft Entra ID per connettersi a queste risorse, vedere quanto segue:
Gli esempi seguenti illustrano come configurare l'applicazione per connettersi alle risorse Azure usando Microsoft Entra ID:
- .NET Aspire: AzurePostgreSQL'integrazione dell'hosting.
- .NET Aspire: AzureRedis'integrazione dell'hosting.
Se è necessario usare l'autenticazione tramite password o chiave di accesso (non consigliata), è possibile abilitarlo con il codice seguente:
var builder = DistributedApplication.CreateBuilder(args);
var pgsql = builder.AddAzurePostgresFlexibleServer("pgsql")
.WithPasswordAuthentication();
var cache = builder.AddAzureRedis("cache")
.WithAccessKeyAuthentication();
Supporto per le funzioni di Azure (in anteprima)
Il supporto per Azure Funzioni è una delle funzionalità più richieste nel .NET.NET Aspire issue tracker e siamo entusiasti di introdurre il supporto di anteprima in questa versione. Per illustrare questo supporto, usiamo .NET.NET Aspire per creare e distribuire un webhook.
Per iniziare, creare un nuovo progetto Funzioni Azure usando la finestra di dialogo Visual Studio Nuovo Progetto. Quando richiesto, selezionare la casella di controllo Enlist in Aspire orchestrazione durante la creazione del progetto.
Nel progetto host dell'app, osserva che c'è un PackageReference al nuovo 📦Aspire.Hosting.Azure.Functions pacchetto NuGet.
<ItemGroup>
<PackageReference Include="Aspire.Hosting.AppHost" Version="9.0.0" />
<PackageReference Include="Aspire.Hosting.Azure.Functions" Version="9.0.0" />
</ItemGroup>
Questo pacchetto fornisce un'API AddAzureFunctionsProject<TProject>(IDistributedApplicationBuilder, String) che può essere richiamata nell'host dell'app per configurare i progetti delle Funzioni Azure all'interno di un host .NET Aspire.
var builder = DistributedApplication.CreateBuilder(args);
builder.AddAzureFunctionsProject<Projects.PigLatinApp>("piglatinapp");
builder.Build().Run();
In questo esempio, il webhook è responsabile della conversione di una stringa di input in Pig Latin. Aggiornare il contenuto del nostro trigger con il codice seguente:
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;
using System.Text;
using FromBodyAttribute = Microsoft.Azure.Functions.Worker.Http.FromBodyAttribute;
namespace PigLatinApp;
public class Function1(ILogger<Function1> logger)
{
public record InputText(string Value);
public record PigLatinText(string Value);
[Function("Function1")]
public IActionResult Run(
[HttpTrigger(AuthorizationLevel.Anonymous, "post")] HttpRequest req,
[FromBody] InputText inputText)
{
logger.LogInformation("C# HTTP trigger function processed a request.");
var result = TranslateToPigLatin(inputText.Value);
return new OkObjectResult(new PigLatinText(result));
}
private static string TranslateToPigLatin(string input)
{
if (string.IsNullOrEmpty(input))
{
return input;
}
var words = input.Split(' ');
StringBuilder pigLatin = new();
foreach (string word in words)
{
if (IsVowel(word[0]))
{
pigLatin.Append(word + "yay ");
}
else
{
int vowelIndex = FindFirstVowelIndex(word);
if (vowelIndex is -1)
{
pigLatin.Append(word + "ay ");
}
else
{
pigLatin.Append(
word.Substring(vowelIndex) + word.Substring(0, vowelIndex) + "ay ");
}
}
}
return pigLatin.ToString().Trim();
}
private static int FindFirstVowelIndex(string word)
{
for (var i = 0; i < word.Length; i++)
{
if (IsVowel(word[i]))
{
return i;
}
}
return -1;
}
private static bool IsVowel(char c) =>
char.ToLower(c) is 'a' or 'e' or 'i' or 'o' or 'u';
}
Impostare un punto di interruzione sulla prima riga logger.LogInformation del metodo Run e premere F5 per avviare l'host delle funzioni. Dopo l'avvio del dashboard .NET.NET Aspire, si osserva quanto segue:
.NET .NET Aspire ha:
- Configurata una risorsa di archiviazione emulata Azure da usare per la contabilità dell'host.
- Avviato localmente l'host di Funzioni con il progetto Funzioni registrato come destinazione.
- La porta definita in launchSettings.json del progetto delle funzioni è stata cablata per l'ascolto.
Usa il tuo client HTTP preferito per inviare una richiesta al trigger e osserva gli input associati dal corpo della richiesta nel debugger.
curl --request POST \
--url http://localhost:7282/api/Function1 \
--header 'Content-Type: application/json' \
--data '{
"value": "Welcome to Azure Functions"
}'
A questo punto è possibile distribuire l'applicazione in Azure Container Apps (ACA). La distribuzione dipende attualmente dalle build di anteprima dei pacchetti di Azure Functions Worker e Worker SDK. Se necessario, aggiornare le versioni a cui si fa riferimento nel progetto Funzioni:
<ItemGroup>
<PackageReference Include="Microsoft.Azure.Functions.Worker" Version="2.0.0-preview2" />
<PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="2.0.0-preview2" />
</ItemGroup>
È anche necessario esporre un endpoint pubblico per il progetto Azure Functions in modo che le richieste possano essere inviate al trigger HTTP:
builder.AddAzureFunctionsProject<Projects.PigLatinApp>("piglatinapp")
.WithExternalHttpEndpoints();
Per distribuire l'applicazione con l'interfaccia a riga di comando azd, è necessario procurarsi prima la versione più recente. Per installare la versione più recente, viene visualizzato un avviso se la versione non è aggiornata. Seguire le istruzioni per eseguire l'aggiornamento alla versione più recente.
Dopo l'installazione, passare alla cartella contenente il progetto host dell'app ed eseguire azd init:
$ azd init
Initializing an app to run on Azure (azd init)
? How do you want to initialize your app? Use code in the current directory
(✓) Done: Scanning app code in current directory
Detected services:
.NET (Aspire)
Detected in: ./PigLatinApp/PigLatinApp.AppHost/PigLatinApp.AppHost.csproj
azd will generate the files necessary to host your app on Azure using Azure Container Apps.
? Select an option Confirm and continue initializing my app
? Enter a new environment name: azfunc-piglatin
Generating files to run your app on Azure:
(✓) Done: Generating ./azure.yaml
(✓) Done: Generating ./next-steps.md
SUCCESS: Your app is ready for the cloud!
Successivamente, distribuisci l'applicazione eseguendo azd up:
$ azd up
? Select an Azure Subscription to use: 130. [redacted]
? Select an Azure location to use: 50. (US) West US 2 (westus2)
Packaging services (azd package)
Provisioning Azure resources (azd provision)
Provisioning Azure resources can take some time.
Subscription: [redacted]
Location: West US 2
You can view detailed progress in the Azure Portal:
[redacted]
(✓) Done: Resource group: rg-azfunc-piglatin (967ms)
(✓) Done: Container Registry: [redacted] (13.316s)
(✓) Done: Log Analytics workspace: [redacted] (16.467s)
(✓) Done: Container Apps Environment: [redacted] (1m35.531s)
(✓) Done: Storage account: [redacted] (21.37s)
Deploying services (azd deploy)
(✓) Done: Deploying service piglatinapp
- Endpoint: {{endpoint-url}}
Aspire Dashboard: {{dashboard-url}}
Testare infine l'applicazione Funzioni che hai distribuito usando il client HTTP preferito:
curl --request POST \
--url {{endpoint-url}}/api/Function1 \
--header 'Content-Type: application/json' \
--data '{
"value": "Welcome to Azure Functions"
}'
Il supporto per le funzioni Azure su .NET Aspire è ancora disponibile in anteprima con supporto per un set limitato di trigger, tra cui:
- i trigger HTTP
- Azure trigger della coda di archiviazione
- Azure Trigger Blob di Archiviazione
- Azure Service Bus attiva
- Azure Event Hubs attiva
Per ulteriori informazioni, vedere l'integrazione ufficiale delle funzioni di .NET AspireAzure (Anteprima).
Personalizzazione di Azure Container Apps
Una delle funzionalità più richieste è la possibilità di personalizzare il Azure Container Apps creato dall'host dell'app senza toccare Bicep. Ciò è possibile usando le API PublishAsAzureContainerApp<T>(IResourceBuilder<T>, Action<AzureResourceInfrastructure,ContainerApp>) e PublishAsAzureContainerApp<T>(IResourceBuilder<T>, Action<AzureResourceInfrastructure,ContainerApp>) nello spazio dei nomi Aspire.Hosting.Azure.AppContainers. Questi metodi personalizzano la definizione del Container App Azure creata dall'host dell'app.
Aggiungere il riferimento al pacchetto al file di progetto:
<ItemGroup>
<PackageReference Include="Aspire.Hosting.Azure.AppContainers"
Version="9.0.0" />
</ItemGroup>
L'esempio seguente illustra come ridimensionare un'applicazione container Azure a zero (0) repliche.
var builder = DistributedApplication.CreateBuilder(args);
var db = builder.AddAzurePostgresFlexibleServer("pg")
.RunAsContainer()
.AddDatabase("db");
// Type is for evaluation purposes only and is subject to change or removal in future updates. Suppress this diagnostic to proceed.
#pragma warning disable AZPROVISION001
builder.AddProject<Projects.WebApplication1>("api")
.WithReference(db)
.PublishAsAzureContainerApp((module, containerApp) =>
{
// Scale to 0
containerApp.Template.Value!.Scale.Value!.MinReplicas = 0;
});
#pragma warning restore AZPROVISION001
builder.Build().Run();
L'esempio di codice precedente rinvia la generazione della definizione della Container App Azure all'host dell'app. In questo modo è possibile personalizzare la definizione dell'App Container Azure senza dover eseguire azd infra synth e modificare in modo insicuro i file bicep generati.
