Azure Functions runtime 1.x legacy reference

Denna artikel bevarar viktig historisk information och länkar till detaljerade referenser för funktionsappar som fortfarande använder runtime 1.x. Använd inte runtime 1.x för nya funktionsappar.

Körtid 1.x-scope

Azure Functions runtime 1.x nådde slutet av stödet den 14 september 2026 och stöds inte för nya eller befintliga funktionsappar. Runtime 1.x hade följande egenskaper:

• Det kördes bara på Windows.
• Den stödde C#-appar som riktade sig mot .NET Framework och JavaScript-appar.
• C#-appar kördes under arbete. Runtime 1.x stödde inte modellen med isolerad arbetare.
• Den använde version 1.x av Azure Functions Core Tools för lokal utveckling. Core Tools 1.x körs bara på Windows.
• Speltiden inkluderade dess stödda bindningar. Senare versioner använder separat versionerade bindningstillägg eller tilläggspaket.

Versioner av körtids-, tilläggs- och programmeringsmodeller

Azure Functions runtime-version är inte densamma som de versioner som används av bindningstillägg, expansionspaket eller språkprogrammeringsmodeller. En versionsetikett på en annan komponent indikerar inte att en app använder Azure Functions runtime 1.x. Ett exempel:

• Programmeringsmodellerna för Python v1 och v2 körs på runtime 4.x.
• Programmeringsmodellerna Node.js v3 och v4 körs på runtime 4.x.
• Versionerna av extension bundle och binding extension package är oberoende av runtime-versionen.

Migrera till runtime 4.x

För att återställa en app till full support, migrera den från runtime 1.x till runtime 4.x. Migrationsguiden täcker dessa uppgifter:

• Identifiera appar som riktar in sig på runtime 1.x.
• Välj ett stödd mål för C# eller JavaScript.
• Uppdatera projektet, bindningar, appinställningar och host.json fil.
• Testa appen lokalt och uppdatera funktionsappen i Azure.

Ändra inte bara FUNCTIONS_EXTENSION_VERSION app-inställningarna. Uppgraderingar i körtid kan kräva projekt-, kod-, bindnings- och konfigurationsändringar.

Appinställningar specifika för runtime 1.x

Den föråldrade AzureWebJobsDashboard inställningen stöds endast av runtime 1.x. Den innehåller en valfri allmän lagringskonto-reťazec pripojenia som används för att lagra loggar och visa dem i fliken Monitor i Azure-portalen.

Runtime 1.x stöder inte appinställningen AZURE_FUNCTIONS_ENVIRONMENT .

Värdet FUNCTIONS_EXTENSION_VERSION~1 fäster en funktionsapp vid runtime 1.x. Filsystemnyckellagring (AzureWebJobsSecretStorageType=files) är standard.

Site-egenskapen functionsRuntimeAdminIsolationEnabled är inte tillgänglig i runtime 1.x. Inställningen FUNCTIONS_V2_COMPATIBILITY_MODE gäller inte för runtime 1.x-appar.

Project- och språkskillnader

Runtime 1.x C#-klassbiblioteksprojekt riktade sig mot .NET Framework och använde version 1.x av paketetMicrosoft.NET.Sdk.Functions. De kan använda dem TraceWriter för skogsverkning. För den aktuella C#-projektmodellen och migreringsöverväganden, se .NET klassbiblioteksutvecklarguiden och runtime 1.x-migreringsguiden.

C#-klassbiblioteksprojekt

Följande exempel visar de relevanta delarna av en runtime 1.x-projektfil:

<PropertyGroup>
  <TargetFramework>net48</TargetFramework>
</PropertyGroup>
<ItemGroup>
  <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.24" />
</ItemGroup>

Paketberoendena Microsoft.NET.Sdk.Functions inkluderar triggers och bindningar. Ett 1.x-projekt syftar på 1.x-triggers och bindningar eftersom de riktar sig mot .NET Framework. Paketet beror också på Newtonsoft.Json och indirekt på WindowsAzure.Storage. Dessa beroenden säkerställer att projektet använder versioner kompatibla med den avsedda Functions-runtimen. Till exempel är Functions-runtimen som riktar sig mot .NET Framework 4.6.1 kompatibel med 9.0.1, inte version Newtonsoft.Json 11.

Runtime 1.x används TraceWriter för Application Insights-loggning. TraceWriter Stöder inte strukturerad loggning.

Följande exempel skapar en TelemetryClient och använder TrackEvent, TrackMetric, och TrackDependency för att spela in anpassad telemetri. Den använder också funktionsexekveringskontexten för att korrelera den anpassade telemetrin med den aktuella anropelsen.

Exempel på anpassad telemetri

using System;
using System.Linq;
using System.Net.Http;
using System.Threading.Tasks;
using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.DataContracts;
using Microsoft.ApplicationInsights.Extensibility;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Extensions.Logging;

namespace functionapp0915
{
	public static class HttpTrigger2
	{
		private static string key = TelemetryConfiguration.Active.InstrumentationKey =
			Environment.GetEnvironmentVariable(
				"APPINSIGHTS_INSTRUMENTATIONKEY", EnvironmentVariableTarget.Process);

		private static TelemetryClient telemetryClient =
			new TelemetryClient() { InstrumentationKey = key };

		[FunctionName("HttpTrigger2")]
		public static async Task<HttpResponseMessage> Run(
			[HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)]
			HttpRequestMessage req, ExecutionContext context, ILogger log)
		{
			log.LogInformation("C# HTTP trigger function processed a request.");
			DateTime start = DateTime.UtcNow;
			string name = req.GetQueryNameValuePairs()
				.FirstOrDefault(q => string.Compare(q.Key, "name", true) == 0)
				.Value;
			dynamic data = await req.Content.ReadAsAsync<object>();
			name = name ?? data?.name;

			var evt = new EventTelemetry("Function called");
			UpdateTelemetryContext(evt.Context, context, name);
			telemetryClient.TrackEvent(evt);

			var metric = new MetricTelemetry("Test Metric", DateTime.Now.Millisecond);
			UpdateTelemetryContext(metric.Context, context, name);
			telemetryClient.TrackMetric(metric);

			var dependency = new DependencyTelemetry
			{
				Name = "GET api/planets/1/",
				Target = "swapi.co",
				Data = "https://swapi.co/api/planets/1/",
				Timestamp = start,
				Duration = DateTime.UtcNow - start,
				Success = true
			};
			UpdateTelemetryContext(dependency.Context, context, name);
			telemetryClient.TrackDependency(dependency);
		}

		private static void UpdateTelemetryContext(
			TelemetryContext context,
			ExecutionContext functionContext,
			string userName)
		{
			context.Operation.Id = functionContext.InvocationId.ToString();
			context.Operation.ParentId = functionContext.InvocationId.ToString();
			context.Operation.Name = functionContext.FunctionName;
			context.User.Id = userName;
		}
	}
}

Runtime 1.x stödde även C#-skript (.csx) och JavaScript-funktioner. C#-skriptet är inte specifikt för runtime 1.x, så använd C#-skriptutvecklarreferensen för allmän manusvägledning. Använd migreringsguiden för ändringar som är specifika för körtid.

För exempel på den tidigare C#-syntaxen, se runtime 1.x-funktionsmallarna.

C#-skriptsammansättningar och paket

I runtime 1.x C#-skriptfunktioner kunde du referera till följande assembler med ett enkelt namn:

• Newtonsoft.Json
• Microsoft.WindowsAzure.Storage
• Microsoft.ServiceBus
• Microsoft.AspNet.WebHooks.Receivers
• Microsoft.AspNet.WebHooks.Common

Runtime 1.x använde en project.json fil för att definiera beroenden. Följande exempel lägger till Microsoft.ProjectOxford.Face NuGet-paketet:

{
	"frameworks": {
		"net46": {
			"dependencies": {
				"Microsoft.ProjectOxford.Face": "1.1.0"
			}
		}
	}
}

Tilläggspaket stöds inte av runtime 1.x. För att använda ett anpassat NuGet-flöde, ange flödet i en NuGet.Config-fil i funktionsappens rotmapp. Mer information finns i Konfigurera NuGet-beteende.

Lokal utveckling med Core Tools 1.x

Version 1.x av Azure Functions Core Tools paras ihop med runtime 1.x och körs endast på Windows. För att starta speltiden sprang func host startdu . För aktuell lokal utvecklingsguidning, se Utveckla Azure Functions lokalt med Core Tools.

Visual Studio lagrade runtime 1.x Core Tools-versioner i %USERPROFILE%\AppData\Local\Azure.Functions.Cli och använde den senaste versionen som lagrades där. Du kunde se den valda versionen i konsolens utdata när du körde projektet:

[3/1/2018 9:59:53 AM] Starting Host (HostId=contoso2-1518597420, Version=2.0.11353.0, ProcessId=22020, Debug=False, Attempt=0, FunctionsExtensionVersion=)

Runtime 1.x host.json referens

Dethost.json schemat och inställningarna ändrades efter runtime 1.x. Se referensen till runtime 1.x host.json när du granskar en befintlig konfiguration och jämför den med den aktuella host.json referensen under migreringen.

Övervaka körtidsappar 1.x med Application Insights

Runtime 1.x använder följande Application Insights-loggkategorier:

Konfigurera loggnivåer

Runtime 1.x konfigurerar loggarnivåer under logger.categoryFilterhost.json:

{
	"logger": {
		"categoryFilter": {
			"defaultLevel": "Warning",
			"categoryLevels": {
				"Host.Results": "Information",
				"Host.Aggregator": "Trace",
				"Function": "Information"
			}
		}
	}
}

När flera kategorinamn börjar med samma sträng matchas den mer specifika kategorin först. Följande exempel loggar allt utom Host.Aggregator på nivån Error :

{
	"logger": {
		"categoryFilter": {
			"defaultLevel": "Information",
			"categoryLevels": {
				"Host": "Error",
				"Function": "Error",
				"Host.Aggregator": "Information"
			}
		}
	}
}

Konfigurera samplingsfrekvens

Den standardmaximala telemetrihastigheten är fem objekt per sekund. Runtime 1.x konfigurerar sampling under applicationInsights.sampling:

{
	"applicationInsights": {
		"sampling": {
			"isEnabled": true,
			"maxTelemetryItemsPerSecond": 5
		}
	}
}

Följande exempel kombinerar kategorifiltrering och urval:

{
	"logger": {
		"categoryFilter": {
			"defaultLevel": "Warning",
			"categoryLevels": {
				"Function": "Error",
				"Host.Aggregator": "Error",
				"Host.Results": "Information",
				"Host.Executor": "Warning"
			}
		}
	},
	"applicationInsights": {
		"sampling": {
			"isEnabled": true,
			"maxTelemetryItemsPerSecond": 5
		}
	}
}

Runtime 1.x stöder inte konfiguration per funktion.

Applikationsinsikter

Runtime 1.x samlade automatiskt in förfrågningar, undantag och prestandaräknare. Den samlade inte automatiskt in HTTP-, Service Bus-, Event Hub- eller SQL-beroenden. Den stödde QuickPulse/Live Metrics utan en säker kontrollkanal och stödde sampling, men den stödde inte heartbeats, Service Bus eller Event Hubs-korrelation eller fullt konfigurerbar telemetriinsamling.

Ej stödda funktioner och beteende i runtime 1.x

• Policyer för omprövning stöds inte.
• Dynamisk skalningsövervakning av virtuella nätverkstriggers stöds inte.
• På Premium- och Dedikerade planer är standardfunktionsexekveringstiden obegränsad. På Consumption-planen är standardtimeout fem minuter och max 10 minuter.
• En funktionsapp som använder ett fjärrutrullningspaket kan inte köras utan en Azure Files-delning.

Bindningar inkluderade i runtime 1.x

Azure Functions runtime 1.x är pensionerad. När du migrerar till runtime 4.x, använd aktuella bindningstillägg eller ett expansionspaket och granska varje bindning för konfigurations- och typändringar.

Följande bindningar inkluderades med runtime 1.x. Kolumnen C#-attribut visar de korta namn som används i koden. De motsvarande klassnamnen har ett Attribute suffix, såsom BlobTriggerAttribute. C#-skriptfunktioner definierar istället bindningar i function.json filen.

Funktionsappar som använder runtime 1.x refererar automatiskt till Microsoft.Azure. WebJobs NuGet-paketet (version 2.x).

Blob Storage, Queue Storage och Table Storage triggers och bindningar använder version 7.2.1 av WindowsAzure.Storage NuGet-paketet. Om du refererar till en annan version av Storage SDK och binder till en Storage SDK-typ i din funktionssignatur, kan Functions-runtimen rapportera att den inte kan binda till den typen. Se till att ditt projekt refererar till WindowsAzure.Storage 7.2.1.

Blob Storage-bindningar i runtime 1.x

Runtime 1.x exponerade typer från det föråldrade Microsoft. WindowsAzure.Storage-namnrymden. Nyare typer från Azure. Lagring. Blobs kräver en senare tillägg och körtid 4.x.

Kölagringsbindningar i runtime 1.x

Runtime 1.x exponerade typer från det föråldrade Microsoft. WindowsAzure.Storage-namnrymden. Nyare typer från Azure. Lagring. Köer kräver en senare tillägg och körning 4.x.

För inställningar för kölagring bindning, se kösektionen i referensen runtime 1.x host.json. I runtime 1.x uttrycks inställningen maxPollingInterval i millisekunder. I senare runtime-versioner är TimeSpandess datatyp .

Table Storage-bindningar i runtime 1.x

Runtime 1.x exponerade typer från det föråldrade Microsoft. WindowsAzure.Storage.Table-namnrymden. Nyare typer från Azure. Data. Tabeller kräver Azure Tables-tillägget och runtime 4.x.

Indataexempel

Följande C#-funktion läser en enda tabellrad. För varje meddelande som skickas till kön triggas funktionen. Radnyckelvärdet {queueTrigger} binder radnyckeln till meddelandemetadata, som är meddelandesträngen.

public class TableStorage
{
	public class MyPoco
	{
		public string PartitionKey { get; set; }
		public string RowKey { get; set; }
		public string Text { get; set; }
	}

	[FunctionName("TableInput")]
	public static void TableInput(
		[QueueTrigger("table-items")] string input,
		[Table("MyTable", "MyPartition", "{queueTrigger}")] MyPoco poco,
		ILogger log)
	{
		log.LogInformation($"PK={poco.PartitionKey}, RK={poco.RowKey}, Text={poco.Text}");
	}
}

Följande C#-funktion läser flera tabellrader där MyPoco klassen härleds från TableEntity.

public class TableStorage
{
	public class MyPoco : TableEntity
	{
		public string Text { get; set; }
	}

	[FunctionName("TableInput")]
	public static void TableInput(
		[QueueTrigger("table-items")] string input,
		[Table("MyTable", "MyPartition")] IQueryable<MyPoco> pocos,
		ILogger log)
	{
		foreach (MyPoco poco in pocos)
		{
			log.LogInformation($"PK={poco.PartitionKey}, RK={poco.RowKey}, Text={poco.Text}");
		}
	}
}

Inmatningsanvändning

Om du vill returnera en specifik entitet efter nyckel använder du en bindningsparameter som härleds från TableEntity. De specifika TableName, PartitionKey, och RowKey används för att försöka få en specifik entitet från tabellen.

Om du vill köra frågor som returnerar flera entiteter binder du till en IQueryable<T> av en typ som ärver från TableEntity.

Utgångsanvändning

Följande typer stöds för out parametrar och returtyper:

• Ett vanligt gammalt CLR-objekt (POCO) som innehåller PartitionKey egenskaperna och RowKey . Du kan följa med dessa egenskaper genom att implementera ITableEntity eller ärva TableEntity.
• ICollector<T> eller IAsyncCollector<T> där T innehåller PartitionKey egenskaperna och RowKey . Du kan följa med dessa egenskaper genom att implementera ITableEntity eller ärva TableEntity.

Du kan också binda till CloudTablefrån Storage SDK som en metodparameter. Du kan sedan använda objektet för att skriva till tabellen.

Event Hubs-bindningar i runtime 1.x

Runtime 1.x inkluderade Event Hubs-bindningen och krävde ingen separat tillägg. Den exponerade den föråldrade Microsoft.Azure. EventHubs.EventData-typen. Event Hubs-triggers stödde EventData, JSON-serialiserbara typer, string, och byte[] för en enskild händelse, samt EventData[] och string[] för en batch. Outputbindningar stöddes EventData, JSON-serialiserbara typer, string, och byte[].

För en Event Hubs-trigger eller utdatabindning i function.jsonanvänder runtime 1.x egenskapen path för event hub-namnet. Senare runtime-versioner använder eventHubName. När händelsehubbets namn också finns i reťazec pripojenia, överskrider det värdet egenskapen vid körning.

Runtime 1.x host.json-filen använder ett objekt på toppnivå eventHub :

{
	"eventHub": {
		"maxBatchSize": 64,
		"prefetchCount": 256,
		"batchCheckpointFrequency": 1
	}
}

För den fullständiga konfigurationsreferensen, se eventHub avsnittet i runtime 1.x host.json-referensen.

Event Grid-bindningar i runtime 1.x

Event Grid-tilläggsversioner äldre än 3.x stöder inte CloudEvents-schemat. För att använda detta schema, använd en HTTP-trigger eller migrera till runtime 4.x och Event Grid-tillägg 3.x.

Event Grid-utdatabindningen är endast tillgänglig för runtime 2.x och senare.

Bindningstyper

Runtime 1.x-tillägget stöder följande parametertyper. Den stöder inte CloudEvents-schemat, som kräver Event Grid-tillägg 3.x.

Användning av utlösare

Funktioner för C#-klassbibliotek under processen stödjer följande Event Grid-triggertyper:

• Newtonsoft.Json.Linq.JObject
• System.String

Webhook-endpoint och systemnyckel

Den hostade webhook-endpointen för en runtime 1.x Event Grid-trigger använder följande URL-mönster:

https://{functionappname}.azurewebsites.net/admin/extensions/EventGridExtensionConfig?functionName={functionname}&code={systemkey}

För att få Event Grid-systemnyckeln från administratörs-API:et, använd funktionen app master key i följande begäran:

https://{functionappname}.azurewebsites.net/admin/host/systemkeys/eventgridextensionconfig_extension?code={masterkey}

För lokal testning använder Event Grid-triggerändpunkten följande URL-mönster:

http://localhost:7071/admin/extensions/EventGridExtensionConfig?functionName={FUNCTION_NAME}

Service Bus-bindningar i runtime 1.x

Runtime 1.x exponerade typer från Microsoft.ServiceBus.Messaging namnrymden i WindowsAzure.ServiceBus, som togs ur bruk för Service Bus-meddelanden den 30 september 2026. Migrera till Service Bus-tillägg 5.x eller senare och kör 4.x för att använda Azure. Messaging. ServiceBus-typer.

Användning av utlösare

Kö- eller ämnesmeddelandetriggern stöder följande parametertyper:

• BrokeredMessage ger dig det deserialiserade meddelandet med metoden BrokeredMessage.GetBody<T>().
• MessageReceiver tar emot och bekräftar meddelanden från meddelandecontainern. Denna typ krävs när autoComplete sätts till false.

I C#-klassbibliotek tar attributets konstruktör namnet på kön eller ämnet och prenumerationen. Du kan också specificera anslutningens åtkomsträttigheter. Om du inte anger åtkomsträttigheter är Managestandardvärdet .

Service Bus-kontoval

Använd ServiceBusAccountAttribute för att specificera Service Bus-kontot. Konstruktorn tar namnet på en appinställning som innehåller en Service Bus reťazec pripojenia. Använd attributet på parameter-, metod- eller klassnivå. Följande exempel visar attribut på klass- och metodnivå:

[ServiceBusAccount("ClassLevelServiceBusAppSetting")]
public static class AzureFunctions
{
	[ServiceBusAccount("MethodLevelServiceBusAppSetting")]
	[FunctionName("ServiceBusQueueTriggerCSharp")]
	public static void Run(
		[ServiceBusTrigger("myqueue", AccessRights.Manage)]
		string myQueueItem, ILogger log)
	{
		// ...
	}
}

Följande ordning avgör vilket Service Bus-konto som ska användas:

1. Attributets ServiceBusTriggerConnection egenskap.
2. Attributet ServiceBusAccount som tillämpas på samma parameter som attributet ServiceBusTrigger .
3. Attributet ServiceBusAccount som tillämpas på funktionen.
4. Attributet ServiceBusAccount som tillämpas på klassen.
5. Appinställningen AzureWebJobsServiceBus .

Meddelandemetadata

Följande egenskaper är medlemmar i klasserna BrokeredMessage och MessageReceiver .

Utgångsanvändning

Använd typen BrokeredMessage när du skickar meddelanden med metadata. Definiera parametrar som return typattribut. Om parametervärdet är null när funktionen avslutas, skapar Functions inget meddelande.

För function.json bindningar, accessRights accepterar manage or listen och går som standard till manage. Om reťazec pripojenia inte har behörighet Hantera, sätt accessRights till listen för att förhindra att runtime försöker hantera hanteringsoperationer.

Runtimen skapar kön om den inte finns och du sätter accessRights till manage.

Värdinställningar

För Service Bus bindningsinställningar, se referensen för runtime 1.x host.json.

HTTP- och webhook-bindningar i runtime 1.x

En HTTP-triggad funktion returnerar HTTP 200 OK med en tom kropp som standard. Senare versioner återvänder HTTP 204 No Content.

För en HTTP-trigger i function.json, använd egenskapen webHookType för att konfigurera triggern att fungera som en webhook-mottagare för den angivna leverantören. Denna egenskap är specifik för runtime 1.x.

Runtime 1.x stöder inte åtkomst till autentiserad klientinformation.

Webhook-läge

Webhook-mallar ger extra validering för webhook-payloads. Bindningsegenskapen webHookType visar webhook-leverantören och styr den stödda payloaden:

När du sätter webHookType, ställ inte in egenskapen methods .

För att svara på GitHub-webhooks, skapa funktionen med en HTTP-trigger, ställ webHookType in till github, och kopiera dess URL och API-nyckel till sidan Add webhook i GitHub-arkivet.

Slack-webhooken genererar en token, så konfigurera en funktionsspecifik nyckel med den token.

Webhook-mottagarkomponenten hanterar webhook-auktorisation. Mekanismen varierar beroende på typ av webhook, men varje mekanism bygger på en nyckel. Som standard används funktionstangenten som är namngiven default . För att använda en annan nyckel, konfigurera webhook-leverantören att skicka nyckelnamnet på ett av följande sätt:

• I frågesträngsparametern clientid , såsom https://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>?clientid=<KEY_NAME>.
• I x-functions-clientid begäran.

För HTTP-bindningsinställningar, se HTTP-avsnittet i runtime 1.x host.json-referensen.

Uppvärmningsutlösare i runtime 1.x

Runtime 1.x stöder inte uppvärmningstriggern.

SendGrid-bindning i runtime 1.x

Lägg till tillägget i projektet genom att installera NuGet-paketet version 2.x.

För inställningar för SendGrid-bindning, se avsnittet SendGrid i referensen för runtime 1.x host.json.

Twilio-bindning i runtime 1.x

Lägg till tillägget i projektet genom att installera NuGet-paketet version 1.x.

För runtime 1.x, använd följande bindningskonfigurationsegenskaper i function.json-filen :

Använd den bevarade bindningsinformationen i denna artikel endast för att förstå en befintlig app. Följ runtime-migreringsguiden och den aktuella bindningsdokumentationen när du uppdaterar appen.

Vanliga frågor och svar

Stöds Azure Functions runtime 1.x fortfarande?

Nej. Stödet för Azure Functions runtime 1.x upphörde den 14 september 2026. Migrera berörda appar till runtime 4.x för fullt stöd.

Använder en Python v1 eller Node.js v4 programmeringsmodell runtime 1.x?

Nej. Versioner av språkprogrammeringsmodeller är oberoende av runtime-versionen. Programmeringsmodellerna Python v1 och v2 samt Node.js v3 och v4 körs på runtime 4.x.

Relaterade resurser

• Compare Azure Functions runtime versions
• Azure Functions runtime 1.x support announcement
• Migrera appar från Azure Functions runtime 1.x till 4.x