Utveckla Azure Functions med hjälp av Visual Studio
Med Visual Studio kan du utveckla, testa och distribuera C#-klassbiblioteksfunktioner till Azure. Om den här upplevelsen är din första med Azure Functions kan du läsa En introduktion till Azure Functions.
Om du vill komma igång direkt kan du slutföra snabbstarten Functions för Visual Studio.
Den här artikeln innehåller information om hur du använder Visual Studio för att utveckla C#-klassbiblioteksfunktioner och publicera dem i Azure. Det finns två modeller för att utveckla C#-klassbiblioteksfunktioner : den isolerade arbetsmodellen och inprocessmodellen.
Du läser den isolerade arbetsmodellversionen den här artikeln. Du kan välja önskad modell överst i artikeln.
Du läser den processbaserade modellversionen den här artikeln. Du kan välja önskad modell överst i artikeln.
Om inget annat anges är procedurer och exempel som visas för Visual Studio 2022. Mer information om Visual Studio 2022-versioner finns i viktig information eller viktig information om förhandsversionen.
Förutsättningar
Visual Studio 2022, inklusive arbetsbelastningen För Azure-utveckling .
Andra resurser som du behöver, till exempel ett Azure Storage-konto, skapas i din prenumeration under publiceringsprocessen.
-
Om du inte har en Azure-prenumeration skapar du ett kostnadsfritt Azure-konto innan du börjar.
Skapa ett Azure Functions-projekt
Azure Functions-projektmallen i Visual Studio skapar ett C#-klassbiblioteksprojekt som du kan publicera till en funktionsapp i Azure. Du kan använda en funktionsapp för att gruppera funktioner som en logisk enhet för enklare hantering, distribution, skalning och delning av resurser.
På Visual Studio-menyn väljer du Arkiv>Nytt>projekt.
I Skapa ett nytt projekt anger du funktioner i sökrutan, väljer Azure Functions-mallen och väljer sedan Nästa.
I Konfigurera det nya projektet anger du ett projektnamn för projektet och väljer sedan Skapa. Funktionsappens namn måste vara ett giltigt C#-namnområde. Du kan inte använda understreck, bindestreck eller andra icke-alfanumeriska tecken.
Använd värdena i följande tabell för inställningarna för att skapa ett nytt Azure Functions-program:
Inställning Värde beskrivning .NET-version .NET 8 Isolerad Det här värdet skapar ett funktionsprojekt som körs i en isolerad arbetsprocess. Isolerad arbetsprocess stöder andra icke-LTS-versioner av .NET och även .NET Framework. Mer information finns i Översikt över Azure Functions-körningsversioner. Funktionsmall HTTP-utlösare Det här värdet skapar en funktion som utlöses av en HTTP-begäran. Lagringskonto (AzureWebJobsStorage) Lagringsemulator Eftersom en funktionsapp i Azure kräver ett lagringskonto tilldelas eller skapas en när du publicerar projektet till Azure. En HTTP-utlösare använder inte ett Azure Storage-konto anslutningssträng. Alla andra utlösartyper kräver ett giltigt Azure Storage-konto anslutningssträng. Auktoriseringsnivå Anonym Funktionen som skapats kan utlösas av alla klienter utan att en nyckel anges. Den här auktoriseringsinställningen gör det enkelt att testa den nya funktionen. Mer information finns i auktoriseringsnivå. Inställning Värde beskrivning .NET-version .NET 8 Det här värdet skapar ett funktionsprojekt som körs i processen med version 4.x av Azure Functions-körningen. Mer information finns i Översikt över Azure Functions-körningsversioner. Funktionsmall HTTP-utlösare Det här värdet skapar en funktion som utlöses av en HTTP-begäran. Lagringskonto (AzureWebJobsStorage) Lagringsemulator Eftersom en funktionsapp i Azure kräver ett lagringskonto tilldelas eller skapas en när du publicerar projektet till Azure. En HTTP-utlösare använder inte ett Azure Storage-konto anslutningssträng. Alla andra utlösartyper kräver ett giltigt Azure Storage-konto anslutningssträng. Auktoriseringsnivå Anonym Funktionen som skapats kan utlösas av alla klienter utan att en nyckel anges. Den här auktoriseringsinställningen gör det enkelt att testa den nya funktionen. Mer information finns i auktoriseringsnivå. Se till att du anger auktoriseringsnivån till Anonym. Om du väljer standardnivån funktion måste du presentera funktionsnyckeln i begäranden för att få åtkomst till funktionsslutpunkten.
Välj Skapa för att skapa funktionsprojektet och funktionen HTTP-utlösare.
När du har skapat ett Azure Functions-projekt skapar projektmallen ett C#-projekt, installerar NuGet-paketen Microsoft.Azure.Functions.Worker
och Microsoft.Azure.Functions.Worker.Sdk
anger målramverket.
När du har skapat ett Azure Functions-projekt skapar projektmallen ett C#-projekt, installerar Microsoft.NET.Sdk.Functions
NuGet-paketet och anger målramverket.
Det nya projektet har följande filer:
host.json: Låter dig konfigurera Functions-värden. De här inställningarna gäller både när du kör lokalt och i Azure. Mer information finns i host.json referens.
local.settings.json: Underhåller inställningar som används när funktioner körs lokalt. De här inställningarna används inte när du kör i Azure. Mer information finns i Filen Lokala inställningar.
Viktigt!
Eftersom den local.settings.json filen kan innehålla hemligheter måste du undanta den från projektkällans kontroll. Kontrollera att inställningen Kopiera till utdatakatalog för den här filen är inställd på Kopiera om den är nyare.
Mer information finns i Projektstruktur i guiden Isolerad arbetare.
Mer information finns i Projekt för functions-klassbibliotek.
Arbeta med appinställningar lokalt
När du kör i en funktionsapp i Azure lagras de inställningar som krävs av dina funktioner på ett säkert sätt i appinställningarna. Under den lokala utvecklingen läggs de här inställningarna i stället till Values
i samlingen i local.settings.json-filen. Filen local.settings.json lagrar även inställningar som används av lokala utvecklingsverktyg.
Objekt i Values
samlingen i projektets local.settings.json fil är avsedda att spegla objekt i funktionsappens programinställningar i Azure.
Visual Studio laddar inte upp inställningarna automatiskt i local.settings.json när du publicerar projektet. För att se till att de här inställningarna också finns i funktionsappen i Azure laddar du upp dem när du har publicerat projektet. Mer information finns i Funktionsappinställningar. Värdena i en ConnectionStrings
samling publiceras aldrig.
Koden kan också läsa funktionsappens inställningsvärden som miljövariabler. Mer information finns i Miljövariabler.
Konfigurera projektet för lokal utveckling
Functions-körningen använder ett Azure Storage-konto internt. För alla andra utlösartyper än HTTP och webhooks anger du Values.AzureWebJobsStorage
nyckeln till ett giltigt Azure Storage-konto anslutningssträng. Funktionsappen kan också använda Azurite-emulatorn för den AzureWebJobsStorage
anslutningsinställning som krävs av projektet. Om du vill använda emulatorn anger du värdet AzureWebJobsStorage
för till UseDevelopmentStorage=true
. Ändra den här inställningen till ett faktiskt lagringskonto anslutningssträng före distributionen. Mer information finns i Lokal lagringsemulator.
Så här anger du lagringskontot anslutningssträng:
Navigera till ditt lagringskonto på Azure-portalen.
På fliken Åtkomstnycklar under Säkerhet + nätverk kopierar du anslutningssträngen för key1.
I projektet öppnar du filen local.settings.json och anger värdet
AzureWebJobsStorage
för nyckeln till den anslutningssträng du kopierade.Upprepa föregående steg för att lägga till unika nycklar i matrisen
Values
för andra anslutningar som krävs av dina funktioner.
Lägga till en funktion i projektet
I C#-klassbiblioteksfunktioner definieras de bindningar som används av funktionen genom att använda attribut i koden. När du skapar funktionsutlösare från de angivna mallarna tillämpas utlösarattributen åt dig.
Högerklicka på projektnoden i Solution Explorer och välj Lägg till>ny Azure-funktion.
Ange ett Namn för klassen och välj sedan Lägg till.
Välj utlösaren, ange de bindningsegenskaper som krävs och välj sedan Lägg till. I följande exempel visas inställningarna för att skapa en utlösarfunktion för kölagring.
För en Azure Storage-tjänstutlösare markerar du rutan Konfigurera anslutning och du uppmanas att välja mellan att använda en Azurite Storage-emulator eller referera till ett etablerat Azure Storage-konto. Välj Nästa och om du väljer ett lagringskonto försöker Visual Studio ansluta till ditt Azure-konto och hämta anslutningssträng. Välj Spara anslutningssträng värde i filen Lokala användarhemligheter och sedan Slutför för att skapa utlösarklassen.
Det här utlösarexemplet använder en programinställning för lagringsanslutningen med en nyckel med namnet
QueueStorage
. Den här nyckeln, som lagras i filen local.settings.json, refererar antingen till Azurite-emulatorn eller ett Azure-lagringskonto.Granska den nyligen tillagda klassen. Följande C#-klass representerar till exempel en grundläggande funktion för kölagringsutlösare:
Du ser en statisk
Run()
metod som tillskrivsFunction
. Det här attributet anger att metoden är startpunkten för funktionen.using System; using Azure.Storage.Queues.Models; using Microsoft.Azure.Functions.Worker; using Microsoft.Extensions.Logging; namespace Company.Function { public class QueueTriggerCSharp { private readonly ILogger<QueueTriggerCSharp> _logger; public QueueTriggerCSharp(ILogger<QueueTriggerCSharp> logger) { _logger = logger; } [Function(nameof(QueueTriggerCSharp))] public void Run([QueueTrigger("PathValue", Connection = "ConnectionValue")] QueueMessage message) { _logger.LogInformation($"C# Queue trigger function processed: {message.MessageText}"); } } }
Du ser en statisk
Run()
metod som tillskrivsFunctionName
. Det här attributet anger att metoden är startpunkten för funktionen.using System; using Microsoft.Azure.WebJobs; using Microsoft.Azure.WebJobs.Host; using Microsoft.Extensions.Logging; namespace Company.Function { public class QueueTriggerCSharp { [FunctionName("QueueTriggerCSharp")] public void Run([QueueTrigger("PathValue", Connection = "ConnectionValue")]string myQueueItem, ILogger log) { log.LogInformation($"C# Queue trigger function processed: {myQueueItem}"); } } }
Ett bindningsspecifikt attribut tillämpas på varje bindningsparameter som tillhandahålls till startpunktsmetoden. Attributet tar bindningsinformationen som parametrar. I föregående exempel har den första parametern ett QueueTrigger
attribut som anger en utlösarfunktion för kölagring. Könamnet och anslutningssträng inställningsnamnet skickas som parametrar till attributetQueueTrigger
. Mer information finns i Azure Queue Storage-bindningar för Azure Functions.
Använd proceduren ovan för att lägga till fler funktioner i funktionsappprojektet. Varje funktion i projektet kan ha en annan utlösare, men en funktion måste ha exakt en utlösare. Mer information finns i Utlösare och bindningar i Azure Functions.
Lägga till bindningar
Precis som med utlösare läggs indata- och utdatabindningar till i funktionen som bindningsattribut. Lägg till bindningar i en funktion på följande sätt:
Se till att du konfigurerar projektet för lokal utveckling.
Lägg till lämpligt NuGet-tilläggspaket för den specifika bindningen genom att hitta de bindningsspecifika NuGet-paketkraven i referensartikeln för bindningen. Du kan till exempel hitta paketkrav för Event Hubs-utlösaren i referensartikeln för Event Hubs-bindning.
Använd följande kommando i Package Manager-konsolen för att installera ett specifikt paket:
Install-Package Microsoft.Azure.Functions.Worker.Extensions.<BINDING_TYPE> -Version <TARGET_VERSION>
Install-Package Microsoft.Azure.WebJobs.Extensions.<BINDING_TYPE> -Version <TARGET_VERSION>
I det här exemplet ersätter du
<BINDING_TYPE>
med namnet som är specifikt för bindningstillägget och<TARGET_VERSION>
med en specifik version av paketet, till exempel4.0.0
. Giltiga versioner visas på de enskilda paketsidorna på NuGet.org.Om det finns appinställningar som bindningen behöver lägger du till
Values
dem i samlingen i den lokala inställningsfilen.Funktionen använder dessa värden när den körs lokalt. När funktionen körs i funktionsappen i Azure använder den inställningarna för funktionsappen. Visual Studio gör det enkelt att publicera lokala inställningar till Azure.
Lägg till lämpligt bindningsattribut i metodsignaturen. I följande exempel utlöser ett kömeddelande funktionen och utdatabindningen skapar ett nytt kömeddelande med samma text i en annan kö.
public class QueueTrigger { private readonly ILogger _logger; public QueueTrigger(ILoggerFactory loggerFactory) { _logger = loggerFactory.CreateLogger<QueueTrigger>(); } [Function("CopyQueueMessage")] [QueueOutput("myqueue-items-destination", Connection = "QueueStorage")] public string Run([QueueTrigger("myqueue-items-source", Connection = "QueueStorage")] string myQueueItem) { _logger.LogInformation($"C# Queue trigger function processed: {myQueueItem}"); return myQueueItem; } }
Attributet
QueueOutput
definierar bindningen för metoden. För flera utdatabindningar skulle du i stället placera det här attributet på en strängegenskap för det returnerade objektet. Mer information finns i Flera utdatabindningar.public static class SimpleExampleWithOutput { [FunctionName("CopyQueueMessage")] public static void Run( [QueueTrigger("myqueue-items-source", Connection = "QueueStorage")] string myQueueItem, [Queue("myqueue-items-destination", Connection = "QueueStorage")] out string myQueueItemCopy, ILogger log) { log.LogInformation($"CopyQueueMessage function processed: {myQueueItem}"); myQueueItemCopy = myQueueItem; } }
Attributet
Queue
för parameternout
definierar utdatabindningen.Anslutningen till Queue Storage hämtas från inställningen
QueueStorage
. Mer information finns i referensartikeln för den specifika bindningen.
En fullständig lista över bindningar som stöds av Functions finns i Bindningar som stöds.
Köra funktioner lokalt
Med Azure Functions Core Tools kan du köra Azure Functions-projekt på din lokala utvecklingsdator. När du trycker på F5 för att felsöka ett Functions-projekt börjar den lokala Functions-värden (func.exe) lyssna på en lokal port (vanligtvis 7071). Alla anropsbara funktionsslutpunkter skrivs till utdata och du kan använda dessa slutpunkter för att testa dina funktioner. Mer information finns i Arbeta med Azure Functions Core Tools. Du uppmanas att installera dessa verktyg första gången du startar en funktion från Visual Studio.
Viktigt!
Från och med version 4.0.6517 av Core Tools måste processmodellprojekt referera till version 4.5.0 eller senare av Microsoft.NET.Sdk.Functions
. Om en tidigare version används func start
får kommandot fel.
Så här startar du funktionen i Visual Studio i felsökningsläge:
Tryck på F5. Om du får en uppmaning accepterar du begäran från Visual Studio för att ladda ned och installera Azure Functions Core (CLI)-verktyg. Du kan också behöva aktivera ett brandväggsfel så att verktygen kan hantera HTTP-begäranden.
När projektet körs testar du koden på samma sätt som du testar en distribuerad funktion.
När du kör Visual Studio i felsökningsläge uppnås brytpunkter som förväntat.
Ett mer detaljerat testscenario med Visual Studio finns i Testa funktioner.
Publicera till Azure
När du publicerar ditt funktionsprojekt i Azure använder Visual Studio zip-distribution för att distribuera projektfilerna. När det är möjligt bör du också välja Run-From-Package så att projektet körs i distributionspaketet (.zip). Mer information finns i Köra dina funktioner från en paketfil i Azure.
Distribuera inte till Azure Functions med hjälp av Web Deploy (msdeploy
).
Följ stegen nedan för att publicera projektet till en funktionsapp i Azure.
I Solution Explorer högerklickar du på projektet och väljer Publicera. I Mål väljer du Azure och sedan Nästa.
På Specifikt mål väljer du Azure-funktionsapp (Windows). En funktionsapp som körs i Windows skapas. Välj Nästa.
I Functions-instansen väljer du Skapa en ny Azure-funktion.
Skapa en ny instans med hjälp av de värden som anges i följande tabell:
Inställning Värde Beskrivning Namn Globalt unikt namn Namn som unikt identifierar din nya funktionsapp. Acceptera det här namnet eller ange ett nytt namn. Giltiga tecken är: a-z
,0-9
och-
.Abonnemang Din prenumeration Den Azure-prenumeration som ska användas. Acceptera den här prenumerationen eller välj en ny i listrutan. Resursgrupp Namnet på resursgruppen Den resursgrupp där du vill skapa funktionsappen. Välj Ny för att skapa en ny resursgrupp. Du kan också välja att använda en befintlig resursgrupp i listrutan. Plantyp Förbrukning När du publicerar projektet till en funktionsapp som körs i en förbrukningsplan betalar du bara för körningar av funktionsappen. Andra värdplaner medför högre kostnader. Plats Plats för apptjänsten Välj en plats i en Azure-region nära dig eller andra tjänster som dina funktioner har åtkomst till. Azure Storage Allmänt lagringskonto Azure Functions-körmiljön kräver ett Azure Storage-konto. Välj Ny för att konfigurera ett allmänt lagringskonto. Du kan också välja att använda ett befintligt konto som uppfyller kraven för lagringskontot. Application Insights Application Insights-instans Du bör aktivera Azure Application Insights-integrering för din funktionsapp. Välj Ny för att skapa en ny instans, antingen i en ny eller i en befintlig Log Analytics-arbetsyta. Du kan också välja att använda en befintlig instans. Välj Skapa för att skapa en funktionsapp och dess relaterade resurser i Azure. Statusen för resursskapande visas i det nedre vänstra hörnet i fönstret.
På Functions-instansen kontrollerar du att kryssrutan Kör från paketfil är markerad. Funktionsappen distribueras med zip-distribution med läget Run-From-Package aktiverat. Zip Deploy är den rekommenderade distributionsmetoden för ditt funktionsprojekt för bättre prestanda.
Välj Slutför och välj Publicera i fönstret Publicera för att distribuera paketet som innehåller dina projektfiler till din nya funktionsapp i Azure.
När distributionen är klar visas rot-URL:en för funktionsappen i Azure på fliken Publicera .
På fliken Publicera i avsnittet Värd väljer du Öppna i Azure Portal. Den nya funktionsappens Azure-resurs öppnas i Azure Portal.
Funktionsappinställningar
Visual Studio laddar inte upp de här inställningarna automatiskt när du publicerar projektet. Alla inställningar som du lägger till i local.settings.json måste du också lägga till i funktionsappen i Azure.
Det enklaste sättet att ladda upp de inställningar som krävs till funktionsappen i Azure är att expandera de tre punkterna bredvid avsnittet Värd och välja länken Hantera Azure App Service-inställningar som visas när du har publicerat projektet.
Om du väljer den här länken visas dialogrutan Programinställningar för funktionsappen, där du kan lägga till nya programinställningar eller ändra befintliga.
Lokalt visas ett inställningsvärde i filen local.settings.json och Remote visar ett aktuellt inställningsvärde i funktionsappen i Azure. Välj Lägg till inställning för att skapa en ny appinställning. Använd infoga-värdet från den lokala länken för att kopiera ett inställningsvärde till fältet Fjärr . Väntande ändringar skrivs till den lokala inställningsfilen och funktionsappen när du väljer OK.
Kommentar
Som standard är local.settings.json-filen inte incheckad i källkontrollen. Det innebär att om du klonar ett lokalt Functions-projekt från källkontrollen har projektet ingen local.settings.json fil. I det här fallet måste du manuellt skapa local.settings.json filen i projektroten så att dialogrutan Programinställningar fungerar som förväntat.
Du kan också hantera programinställningar på något av följande sätt:
- Använda Azure-portalen.
- Använd publiceringsalternativet
--publish-local-settings
i Azure Functions Core Tools. - Använd Azure CLI.
Fjärrfelsökning
Om du vill felsöka funktionsappen via fjärranslutning måste du publicera en felsökningskonfiguration för projektet. Du måste också aktivera fjärrfelsökning i funktionsappen i Azure.
Det här avsnittet förutsätter att du redan har publicerat till funktionsappen med hjälp av en versionskonfiguration.
Överväganden för fjärrfelsökning
- Fjärrfelsökning rekommenderas inte för en produktionstjänst.
- Om felsökning av Just My Code är aktiverat inaktiverar du det.
- Undvik långa stopp vid brytpunkter vid fjärrfelsökning. Azure behandlar en process som har stoppats längre än några minuter som en process som inte svarar och stänger av den.
- När du felsöker skickar servern data till Visual Studio, vilket kan påverka bandbreddsavgifterna. Information om bandbreddshastigheter finns i Priser för Azure.
- Fjärrfelsökning inaktiveras automatiskt i funktionsappen efter 48 timmar. Efter 48 timmar måste du återaktivera fjärrfelsökning.
Bifoga felsökningsprogrammet
Hur du kopplar felsökningsprogrammet beror på körningsläget. När du felsöker en isolerad arbetsprocessapp måste du för närvarande koppla fjärrfelsökaren till en separat .NET-process, och flera andra konfigurationssteg krävs.
När du är klar bör du inaktivera fjärrfelsökning.
Så här kopplar du en fjärrfelsökare till en funktionsapp som körs i en process som är separat från Functions-värden:
På fliken Publicera väljer du ellipserna (...) i avsnittet Värd och väljer sedan Ladda ned publiceringsprofil. Den här åtgärden laddar ned en kopia av publiceringsprofilen och öppnar nedladdningsplatsen. Du behöver den här filen, som innehåller de autentiseringsuppgifter som används för att koppla till den isolerade arbetsprocess som körs i Azure.
Varning
Filen .publishsettings innehåller dina autentiseringsuppgifter (okodade) som används för att administrera funktionsappen. Bästa praxis för den här filen är att tillfälligt lagra den utanför källkatalogerna (till exempel i mappen Bibliotek\Dokument) och sedan ta bort den när den inte längre behövs. En obehörig användare som får åtkomst till .publishsettings-filen kan redigera, skapa och ta bort funktionsappen.
På fliken Publicera väljer du ellipserna (...) i avsnittet Värd och väljer sedan Bifoga felsökningsprogram.
Visual Studio ansluter till funktionsappen och aktiverar fjärrfelsökning, om den inte redan är aktiverad.
Kommentar
Eftersom fjärrfelsökaren inte kan ansluta till värdprocessen kan du se ett fel. I vilket fall som helst bryter standardfelsökningen inte in i koden.
Tillbaka i Visual Studio kopierar du URL:en för webbplatsen under Värd på sidan Publicera.
På menyn Felsök väljer du Anslut till process. I fönstret Anslut till process klistrar du in URL:en i anslutningsmålet, tar bort
https://
och lägger till porten:4024
.Kontrollera att målet ser ut som
<FUNCTION_APP>.azurewebsites.net:4024
och tryck på Retur.Om du uppmanas att göra det kan du tillåta Visual Studio-åtkomst via din lokala brandvägg.
När du uppmanas att ange autentiseringsuppgifter väljer du ett annat konto i stället för lokala autentiseringsuppgifter (Fler alternativ i Windows). Ange värdena för userName och userPWD från den publicerade profilen för e-postadress och lösenord i autentiseringsdialogrutan i Windows. När en säker anslutning har upprättats med distributionsservern visas de tillgängliga processerna.
Kontrollera Visa process från alla användare och välj sedan dotnet.exe och välj Bifoga. När åtgärden är klar är du kopplad till C#-klassbibliotekskoden som körs i en isolerad arbetsprocess. Nu kan du felsöka funktionsappen som vanligt.
Så här kopplar du en fjärrfelsökare till en funktionsapp som körs i processen med Functions-värden:
På fliken Publicera väljer du ellipserna (...) i avsnittet Värd och väljer sedan Bifoga felsökningsprogram.
Visual Studio ansluter till funktionsappen och aktiverar fjärrfelsökning, om den inte redan är aktiverad. Den letar också upp och kopplar felsökningsprogrammet till värdprocessen för appen. Nu kan du felsöka funktionsappen som vanligt.
Inaktivera fjärrfelsökning
När du har fjärrfelsökt koden bör du inaktivera fjärrfelsökning i Azure Portal. Fjärrfelsökning inaktiveras automatiskt efter 48 timmar, om du glömmer det.
På fliken Publicera i projektet väljer du ellipserna (...) i avsnittet Värd och väljer Öppna i Azure Portal. Den här åtgärden öppnar funktionsappen i den Azure Portal som projektet distribueras till.
I funktionsappen väljer du Konfiguration under inställningar, väljer Allmänna inställningar, ställer in Fjärrfelsökning till Av och väljer Spara och sedan Fortsätt.
När funktionsappen har startats om kan du inte längre fjärransluta till dina fjärrprocesser. Du kan använda samma flik i Azure Portal för att aktivera fjärrfelsökning utanför Visual Studio.
Övervakningsfunktioner
Det rekommenderade sättet att övervaka körningen av dina funktioner är genom att integrera funktionsappen med Azure Application Insights. Du bör aktivera den här integreringen när du skapar din funktionsapp under Visual Studio-publicering.
Om integreringen av någon anledning inte gjordes under publiceringen bör du fortfarande aktivera Application Insights-integrering för funktionsappen i Azure.
Mer information om övervakning med Application Insights finns i Övervaka Azure Functions.
Testa funktioner
I det här avsnittet beskrivs hur du skapar ett C#-modellprojekt som du kan testa med xUnit.
1. Installation
Använd de här stegen för att konfigurera miljön, inklusive appprojektet och funktionerna, som krävs för att stödja dina tester:
- Skapa en ny Functions-app och ge den namnet Functions
- Skapa en HTTP-funktion från mallen och ge den namnet MyHttpTrigger.
- Skapa en timerfunktion från mallen och ge den namnet MyTimerTrigger.
- Skapa en xUnit-testapp i lösningen och ge den namnet Functions.Tests. Ta bort standardtestfilerna.
- Använd NuGet för att lägga till en referens från testappen till Microsoft.AspNetCore.Mvc
- Referera till Functions-appen från Functions.Tests-appen.
Nu när projekten har skapats kan du skapa de klasser som används för att köra de automatiserade testerna.
2. Skapa testklasser
Varje funktion tar en instans av ILogger
för att hantera meddelandeloggning. Vissa tester loggar antingen inte meddelanden eller bryr sig inte om hur loggning implementeras. Andra tester måste utvärdera meddelanden som loggas för att avgöra om ett test skickas.
Skapa en klass med namnet
ListLogger
, som innehåller en intern lista över meddelanden som ska utvärderas under testningen. För att implementera det nödvändigaILogger
gränssnittet behöver klassen ett omfång. I följande klass hånas ett omfång för testfallen som ska skickasListLogger
till klassen.Skapa en ny klass i ditt Functions.Tests-projekt med namnet NullScope.cs och lägg till den här koden:
using System; namespace Functions.Tests { public class NullScope : IDisposable { public static NullScope Instance { get; } = new NullScope(); private NullScope() { } public void Dispose() { } } }
Skapa en klass i ditt Functions.Tests-projekt med namnet ListLogger.cs och lägg till den här koden:
using Microsoft.Extensions.Logging; using System; using System.Collections.Generic; using System.Text; namespace Functions.Tests { public class ListLogger : ILogger { public IList<string> Logs; public IDisposable BeginScope<TState>(TState state) => NullScope.Instance; public bool IsEnabled(LogLevel logLevel) => false; public ListLogger() { this.Logs = new List<string>(); } public void Log<TState>(LogLevel logLevel, EventId eventId, TState state, Exception exception, Func<TState, Exception, string> formatter) { string message = formatter(state, exception); this.Logs.Add(message); } } }
Klassen
ListLogger
implementerar följande medlemmar enligt gränssnittetsILogger
kontrakt:BeginScope: Omfång lägger till kontext i loggningen. I det här fallet pekar testet bara på den statiska instansen
NullScope
i klassen så att testet kan fungera.IsEnabled: Ett standardvärde
false
för anges.Logg: Den här metoden använder den angivna
formatter
funktionen för att formatera meddelandet och lägger sedan till den resulterande texten iLogs
samlingen.
Samlingen
Logs
är en instans avList<string>
och initieras i konstruktorn.Skapa en kodfil i Functions.Tests-projektet med namnet LoggerTypes.cs och lägg till den här koden:
namespace Functions.Tests { public enum LoggerTypes { Null, List } }
Den här uppräkningen anger vilken typ av loggning som används av testerna.
Skapa en klass i Functions.Tests-projektet med namnet TestFactory.cs och lägg till den här koden:
using Microsoft.AspNetCore.Http; using Microsoft.AspNetCore.Http.Internal; using Microsoft.Extensions.Logging; using Microsoft.Extensions.Logging.Abstractions; using Microsoft.Extensions.Primitives; using System.Collections.Generic; namespace Functions.Tests { public class TestFactory { public static IEnumerable<object[]> Data() { return new List<object[]> { new object[] { "name", "Bill" }, new object[] { "name", "Paul" }, new object[] { "name", "Steve" } }; } private static Dictionary<string, StringValues> CreateDictionary(string key, string value) { var qs = new Dictionary<string, StringValues> { { key, value } }; return qs; } public static HttpRequest CreateHttpRequest(string queryStringKey, string queryStringValue) { var context = new DefaultHttpContext(); var request = context.Request; request.Query = new QueryCollection(CreateDictionary(queryStringKey, queryStringValue)); return request; } public static ILogger CreateLogger(LoggerTypes type = LoggerTypes.Null) { ILogger logger; if (type == LoggerTypes.List) { logger = new ListLogger(); } else { logger = NullLoggerFactory.Instance.CreateLogger("Null Logger"); } return logger; } } }
Klassen
TestFactory
implementerar följande medlemmar:Data: Den här egenskapen returnerar en IEnumerable-samling med exempeldata. Nyckelvärdeparen representerar värden som skickas till en frågesträng.
CreateDictionary: Den här metoden accepterar ett nyckel/värde-par som argument och returnerar en ny
Dictionary
som används för att skapaQueryCollection
för att representera frågesträngsvärden.CreateHttpRequest: Den här metoden skapar en HTTP-begäran som initieras med de angivna frågesträngsparametrarna.
CreateLogger: Baserat på loggningstypen returnerar den här metoden en loggerklass som används för testning. Håller
ListLogger
reda på loggade meddelanden som är tillgängliga för utvärdering i tester.
Skapa en klass i Functions.Tests-projektet med namnet FunctionsTests.cs och lägg till den här koden:
using Microsoft.AspNetCore.Mvc; using Microsoft.Extensions.Logging; using Xunit; namespace Functions.Tests { public class FunctionsTests { private readonly ILogger logger = TestFactory.CreateLogger(); [Fact] public async void Http_trigger_should_return_known_string() { var request = TestFactory.CreateHttpRequest("name", "Bill"); var response = (OkObjectResult)await MyHttpTrigger.Run(request, logger); Assert.Equal("Hello, Bill. This HTTP triggered function executed successfully.", response.Value); } [Theory] [MemberData(nameof(TestFactory.Data), MemberType = typeof(TestFactory))] public async void Http_trigger_should_return_known_string_from_member_data(string queryStringKey, string queryStringValue) { var request = TestFactory.CreateHttpRequest(queryStringKey, queryStringValue); var response = (OkObjectResult)await MyHttpTrigger.Run(request, logger); Assert.Equal($"Hello, {queryStringValue}. This HTTP triggered function executed successfully.", response.Value); } [Fact] public void Timer_should_log_message() { var logger = (ListLogger)TestFactory.CreateLogger(LoggerTypes.List); new MyTimerTrigger().Run(null, logger); var msg = logger.Logs[0]; Assert.Contains("C# Timer trigger function executed at", msg); } } }
De medlemmar som implementeras i den här klassen är:
Http_trigger_should_return_known_string: Det här testet skapar en begäran med frågesträngsvärdena
name=Bill
för till en HTTP-funktion och kontrollerar att det förväntade svaret returneras.Http_trigger_should_return_string_from_member_data: Det här testet använder xUnit-attribut för att tillhandahålla exempeldata till HTTP-funktionen.
Timer_should_log_message: Det här testet skapar en instans av
ListLogger
och skickar den till en timerfunktion. När funktionen har körts kontrolleras loggen för att kontrollera att det förväntade meddelandet finns.
Om du vill komma åt programinställningarna i dina tester kan du mata in en
IConfiguration
instans med simulerade miljövariabelvärden i din funktion.
3. Kör tester
Om du vill köra testerna går du till Testutforskaren och väljer Kör alla tester i vyn.
4. Felsöka tester
Om du vill felsöka testerna anger du en brytpunkt för ett test, navigerar till Testutforskaren och väljer Kör > felsökning senaste körning.
Nästa steg
Mer information om Azure Functions Core Tools finns i Arbeta med Azure Functions Core Tools.