Cloud-Native | The .NET Blog

azd-hooks in Python, TypeScript en .NET: genoeg van shell-scripts

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Dit bericht is automatisch vertaald. Voor de originele versie, klik hier.

Als je ooit een volledig .NET-project had en toch Bash-scripts moest schrijven voor azd-hooks, dan ken je dat gevoel maar al te goed. Waarom overstappen naar shell-syntax voor een pre-provisioning stap wanneer de rest van het project C# is?

Die frustratie heeft nu een officiële oplossing. De Azure Developer CLI heeft multi-taalondersteuning voor hooks uitgebracht, en het is precies zo goed als het klinkt.

Wat zijn hooks

Hooks zijn scripts die worden uitgevoerd op cruciale momenten in de azd-levenscyclus — voor provisioning, na deployment, en meer. Ze worden gedefinieerd in azure.yaml en maken het mogelijk om aangepaste logica te injecteren zonder de CLI aan te passen.

Voorheen werden alleen Bash en PowerShell ondersteund. Nu kun je Python, JavaScript, TypeScript of .NET gebruiken — en azd regelt de rest automatisch.

Hoe detectie werkt

Wijs de hook naar een bestand en azd leidt de taal af uit de extensie:

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

Geen extra configuratie nodig. Als de extensie onduidelijk is, kun je kind: python (of de betreffende taal) expliciet toevoegen.

Taalspecifieke details

Python

Plaats een requirements.txt of pyproject.toml naast het script (of in een bovenliggende map). azd maakt automatisch een virtuele omgeving, installeert afhankelijkheden en voert het script uit.

JavaScript en TypeScript

Hetzelfde patroon — een package.json bij het script en azd voert eerst npm install uit. Voor TypeScript wordt npx tsx gebruikt, zonder compilatiestap en zonder tsconfig.json.

.NET

Twee beschikbare modi:

Projectmodus: Als er een .csproj naast het script staat, voert azd automatisch dotnet restore en dotnet build uit.
Single-file modus: Op .NET 10+ kunnen zelfstandige .cs-bestanden direct worden uitgevoerd via dotnet run script.cs. Geen projectbestand vereist.

Executor-specifieke configuratie

Elke taal ondersteunt een optioneel config-blok:

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

Waarom dit belangrijk is voor .NET-ontwikkelaars

Hooks waren de laatste plek in een azd-gebaseerd project die een taalwissel afdwong. Nu kan de volledige deployment pipeline — van applicatiecode tot lifecycle-hooks — in één taal leven. Bestaande .NET-utilities zijn herbruikbaar in hooks, gedeelde bibliotheken kunnen worden gerefereerd en shell-scriptonderhoud is verleden tijd.

Conclusie

Een van die veranderingen die klein lijken maar dagelijks veel wrijving uit de azd-workflow halen. Multi-taalondersteuning voor hooks is nu beschikbaar — bekijk de officiële post voor de volledige documentatie.

Aspire 13.2 Krijgt MongoDB EF Core en Azure Data Lake — Twee Integraties Die het Proberen Waard Zijn

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Dit bericht is automatisch vertaald. Voor het origineel, klik hier.

Aspire 13.2 is geland met twee nieuwe database-integraties die de moeite waard zijn: MongoDB Entity Framework Core en Azure Data Lake Storage.

MongoDB ontmoet EF Core in Aspire

Aspire ondersteunde MongoDB al een tijdje, maar het was altijd de ruwe driver — geen EF Core, geen DbContext, geen LINQ-query’s. Nu krijg je de volledige EF Core-ervaring met MongoDB, samen met Aspire’s automatische health checks en service discovery.

Instellingen in AppHost:

var mongodb = builder.AddMongoDB("mongodb")
 .WithDataVolume()
 .WithLifetime(ContainerLifetime.Persistent);

var apiService = builder.AddProject<Projects.ApiService>("api")
 .WithReference(mongodb);

In het verbruikende project:

dotnet add package Aspire.MongoDB.EntityFrameworkCore

Registreer je DbContext:

builder.AddMongoDbContext<MyDbContext>("mongodb", "mydb");

De integratie regelt connection pooling, OpenTelemetry-traces en health checks achter de schermen.

Azure Data Lake Storage doet mee

In AppHost:

var storage = builder.AddAzureStorage("azure-storage");
var dataLake = storage.AddDataLake("data-lake");
var fileSystem = storage.AddDataLakeFileSystem("data-lake-file-system");

var analyticsService = builder.AddProject<Projects.AnalyticsService>("analytics")
 .WithReference(dataLake)
 .WithReference(fileSystem);

In het verbruikende project:

builder.AddAzureDataLakeServiceClient("data-lake");
builder.AddAzureDataLakeFileSystemClient("data-lake-file-system");

Geen handmatig beheer van verbindingsstrings, geen zoektocht naar inloggegevens.

Samenvatting

Aspire 13.2 is een incrementele release, maar de MongoDB EF Core en Data Lake-integraties vullen echte gaten. Upgrade naar 13.2 en probeer ze uit.

Azure Smart Tier is GA — Automatische Blob Storage Kostenoptimalisatie Zonder Levenscyclusregels

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Dit bericht is automatisch vertaald. Voor het origineel, klik hier.

Als je ooit tijd hebt besteed aan het afstemmen van Azure Blob Storage-levenscyclusbeleid en dit zag instorten wanneer toegangspatronen veranderden, is dit voor jou. Microsoft heeft zojuist de algemene beschikbaarheid van smart tier voor Azure Blob en Data Lake Storage aangekondigd.

Wat smart tier eigenlijk doet

Smart tier evalueert continu de tijd van laatste toegang van elk object in je opslagaccount. Frequent geraadpleegde gegevens blijven in hot, inactieve gegevens worden na 30 dagen naar cool verplaatst, daarna na nog eens 60 dagen naar cold. Wanneer gegevens opnieuw worden geopend, worden ze direct terug gepromoveerd naar hot.

Geen levenscyclusregels om te configureren. Geen handmatige afstemming.

Tijdens de preview meldde Microsoft dat meer dan 50% van de door smart tier beheerde capaciteit automatisch naar koelere lagen is verschoven.

Waarom dit belangrijk is voor .NET-ontwikkelaars

Praktische scenario’s:

Applicatietelemetrie en logboeken — hot bij foutopsporing, zelden geopend na een paar weken
Datapijplijnen en ETL-uitvoer — intensief benaderd tijdens verwerking, daarna meestal cold
Door gebruikers gegenereerde content — recente uploads zijn hot, oudere content koelt geleidelijk af

De afweging

De tieringregels van smart tier zijn statisch (30 dagen → cool, 90 dagen → cold). Als je aangepaste drempels nodig hebt, zijn levenscyclusregels nog steeds de weg te gaan.

Waar Moet Je je AI-Agents op Azure Hosten? Een Praktische Beslissingswijzer

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Dit bericht is automatisch vertaald. Voor het origineel, klik hier.

Als je momenteel AI-agents bouwt met .NET, heb je waarschijnlijk iets opgemerkt: er zijn veel manieren om ze te hosten op Azure. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents.

Microsoft heeft zojuist een uitgebreide gids voor Azure AI agent-hosting gepubliceerd.

De zes opties in één oogopslag

Optie	Beste voor	Je beheert
Container Apps	Volledige containercontrole zonder K8s	Observabiliteit, staat, levenscyclus
AKS	Enterprise-naleving, multi-cluster	Alles
Azure Functions	Event-gedreven, korte taken	Bijna niets
App Service	Eenvoudige HTTP-agents	Implementatie, schaling
Foundry Agents	Optionele code-agents	Bijna niets
Foundry Hosted Agents	Aangepaste framework-agents	Alleen je agentcode

Foundry Hosted Agents — het juiste midden voor .NET agentdevelopers

Implementatie is echt eenvoudig:

azd ext install azure.ai.agents
azd ai agent init
azd up

Die ene azd up bouwt je container, stuurt hem naar ACR, richt het Foundry-project in en start je agent.

Mijn beslissingsraamwerk

Nul infrastructuur nodig? → Foundry Agents
Eigen agentcode maar beheerde hosting gewenst? → Foundry Hosted Agents
Event-gedreven, korte taken? → Azure Functions
Maximale containercontrole? → Container Apps
Strikte naleving en multi-cluster? → AKS

Samenvatting

Voor de meeste .NET-ontwikkelaars die bouwen met Semantic Kernel of Microsoft Agent Framework, is Hosted Agents waarschijnlijk het juiste startpunt. Bekijk de volledige gids van Microsoft.

KubeCon Europe 2026: Waar .NET-ontwikkelaars Echt Op Moeten Letten

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

Dit bericht is automatisch vertaald. Voor het origineel, klik hier.

Microsoft publiceerde zojuist hun volledige KubeCon Europe 2026-samenvatting.

mTLS zonder service mesh-belasting

Azure Kubernetes Application Network geeft je onderlinge TLS, applicatiebewuste autorisatie en verkeerstelemetrie — zonder een volledige sidecar-mesh. Je ASP.NET Core API’s die met achtergrondworkers communiceren — alles versleuteld op netwerkniveau, zonder wijzigingen in applicatiecode.

GPU-observeerbaarheid

AKS toont nu GPU-metrics native in beheerde Prometheus en Grafana. Geen aangepaste exporteurs.

Netwerken over clusters heen

Azure Kubernetes Fleet Manager levert nu cross-cluster-netwerken — unified connectivity, globaal serviceregister.

Veiligere upgrades

Blauw-groene agent pool-upgrades maken een parallel knooppuntpool. Agent pool-terugdraaien laat je terugkeren naar de vorige versie.

Waar te beginnen

Observeerbaarheid eerst — schakel GPU-metrics en netwerkstroomlogboeken in
Probeer blauw-groene upgrades — test de terugdraaiworkflow
Pilot identiteitsbewust netwerken — schakel mTLS in voor één servicepad