It will be deployed by the end of August.

Once deployed, you can use it by setting WEBSITE_NODE_DEFAULT_VERSION to 8.4.0 in your Azure App Settings.

This deployment will also include 6.11.2, the latest 6.x build.

Microsoft.NET.Sdk.Functions 1.0.5 has been released.
This release includes fix for .NETStandard 2.0 class libraries.

In the next release of Azure Web Apps, we will update the PHP stacks to the latest available versions.
For information on the changes in the new versions, please see the change logs on the PHP website.

The next release should go out mid-July.

edit: add expected release date.

A new version of the Azure Functions Core Tools has been released. This includes Azure Functions runtime 1.0.11002.0 see #7

Please refer to the release info here https://github.com/Azure/azure-functions-cli/releases/tag/0.98

We will be deploying .NET Framework 4.7.1 in December 2017 to Azure App Service worldwide. Currently, it is running 4.7.

Please make sure to test your apps locally against 4.7.1 to make sure you are not negatively affected. Even though it should be a very non-breaking release, small incompatibilities are always possible, and preparedness will help smooth the transition.

See https://blogs.msdn.microsoft.com/dotnet/2017/10/17/announcing-the-net-framework-4-7-1/ for more details about this release.

Important announcement about the retirement of PHP 5.5 from App Service:

Because the PHP Group stated that PHP 5.5 is no longer supported, there won’t be any more updates to that version, including security fixes. To avoid the potential for security issues on App Service, we plan to retire our support of PHP 5.5 in January 2018. Currently, we support PHP 5.6, 7.0 and 7.1.

This retirement will impact all customers who are running their Web App on the PHP 5.5 runtime (unless you are using a custom PHP runtime). We strongly recommend that you upgrade to a supported version of PHP because your Web App will be auto-moved to PHP 5.6. For more information on how to migrate from PHP 5.5 to another version of PHP, please review the documentation on the Appendices webpage on PHP.net. 

Although we’re removing the PHP 5.5 runtime from the platform, we’re aware that some applications are complex and may be tied to a specific PHP runtime version. In order to continue to support your PHP 5.5 applications, it’s possible to remain on PHP 5.5 runtime. For more information, please visit the “How to: Use a custom PHP runtime” section of the  Configure PHP in Azure App Service Web Apps documentation webpage. 

In the not so distant future (no ETA yet), we will release version 2.0 of the Functions runtime. Normally, Function Apps have their FUNCTIONS_EXTENSION_VERSION app setting set to ~1, which means they will continue to run 1.x after 2.x is released. This is a good things since 2.x will have some breaking changes.

However, a small percentage of apps don't have FUNCTIONS_EXTENSION_VERSION set at all, or have it set to latest. These, will automatically move up to the 2.x runtime once it is released. If you are in this situation, make sure that it is the behavior that you want. If not, please change the app setting to ~1.

Please use Azure/app-service-announcements-discussions#11 is you have any questions.

A new version of the Azure Functions Core Tools has been released. This includes Azure Functions runtime 1.0.11232. See #39 for details.

Please refer to the release info here https://github.com/Azure/azure-functions-cli/releases/tag/1.0.4

Release 2.7 (Sprint 7) of the portal is release here https://portal.azure.com/

Here are the release notes https://github.com/Azure/azure-functions-ux/releases/tag/2.7

Today, we released a new version of the Functions Portal UI. Please see https://github.com/Azure/azure-functions-ux/releases/tag/v2.8 for details.

A new version of the Azure Functions Runtime (script host), 1.0.11296 is being deployed.

Please refer to the latest release notes on the release page here for details.

Please use Azure/app-service-announcements-discussions#14 for discussions related to this release.

A new version of the Azure Functions Runtime (script host), 1.0.110015 is being deployed.

Please refer to the latest release notes on the release page here for details.

A new version of the Azure Functions Runtime (script host), 1.0.11232 is being deployed.

Please refer to the latest release notes on the release page here for details.

Please use Azure/app-service-announcements-discussions#13 for discussions related to this release.

https://github.com/nodejs/LTS shows the full Node support schedule. Versions that are no longer maintained will be removed from App Service starting in October 2017.

8/7/0. the latest version of Node, is now available. Please see https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V8.md#8.7.0 for details on the changes.

A new version of the Azure Functions Runtime (script host), 1.0.110027 is being deployed.

Please refer to the latest release notes on the release page here for details.

Please use Azure/app-service-announcements-discussions#3 for discussions related to this release.

Today, we released a new version of the Functions Portal UI. Please see https://github.com/Azure/azure-functions-ux/releases/tag/2.9 for details.

Today, we released a new version of the Functions Portal UI. Please see https://github.com/Azure/azure-functions-ux/releases/tag/v2.3.1 for details.

Today, we released a new version of the Functions Portal UI. Please see https://github.com/Azure/azure-functions-ux/releases/tag/2.10

A NuGet configuration change is currently impacting some Azure Functions customers who may see a failure during the restore process with the following error:

Invalid input ‘project.json’. Provide the path of an msbuild solution file instead.
Support for XProj and standalone project.json files has been removed, to continue
working with legacy projects use NuGet 3.5.x from https://nuget.org/download

A fix will soon be deployed to impacted sites, but workaround documented below may be used in the meantime.

Workaround

Impacted customers can create the following App Setting ( Platform Features > Application Settings on the portal):

Name: AzureWebJobs_NuGetPath

Value: D:\Program Files (x86)\SiteExtensions\Kudu\62.60515.2845\bin\Scripts\nuget.exe

NOTE: This is a temporary workaround that should be removed to prevent issues when the problem is addressed. If you apply this workaround, please watch this issue for updates so you can remove the workaround when it is no longer needed.

A new version of the Azure Functions Core Tools has been released. This includes Azure Functions runtime 1.0.110015 see #10

Please refer to the release info here https://github.com/Azure/azure-functions-cli/releases/tag/0.100

We are tracking an issue with the Try Functions UI (https://github.com/Azure/azure-functions-ux/issues/1682) .

As a workaround feel free to use https://functions-next.azure.com/try till the fix is propagated to production.

Microsoft.NET.Sdk.Functions 1.0.6 has been released.
This release includes fix for path issues on Unix systems.

Today, we released a new version of the Functions Portal UI. Please see https://github.com/Azure/azure-functions-ux/releases/tag/v2.3.0 for details.

We're in the process of releasing Node 8 and npm 5 to App Service on Windows. We expect the deployment to complete by the end of the week (5/2).

See https://nodejs.org/en/blog/release/v8.0.0/ for details on Node 8.

In the most recent version of the Functions runtime (1.0.11296.0) we have introduced a few breaking changes in regards to how Functions Proxies behave.

The following application will be removed from the Azure marketplace in the next few days

• Openatrium by AppDirect
• Typo3CMS by AppDirect
• Piwik by AppDirect
• SugarCRM by AppDirect
• OsCommerce by AppDirect
• Pligg by AppDirect

Impact:

If an application is removed from the marketplace , this means it is no longer supported by the application owner in the marketplace. In such cases we remove the application if it does have support from the application owner to maintain fixes or issues. If you want to deploy the same application , you can. Follow these steps to do so :

• Create an empty Web App and any additional resources such as MySQL , SQL DB etc that the application may need.
• Access the web application file storage and deploy the code via FTP or GIT.
• Browse the application and complete the installation of the application based on the documentation provided in the application framework documentation.
• If you run into issues , please report these issues in the community forums for the application being used .

Checkout our FAQ for more details.

Release 2.5 (Sprint 5) of the portal is scheduled for Monday (7/10). You can try it here https://portal.azure.com/?appsvc.env=stage

Here is the draft release https://github.com/Azure/azure-functions-ux/releases/tag/v2.5

Can we please, I'm begging, get a 64-bit version of the node.exe available in the Azure web app base?

I know I can bring my own node.exe. Except that when I use my own I can't replace it while the application is in use (git repo pushes). Not to mention issues with the path to that executable depending on environments.

You're already providing the 32-bit version. Is there any particular reason the 64-bit versions aren't copied as well?

A new version of the Azure Functions Core Tools has been released. This includes Azure Functions runtime 1.0.11075.0 see #23

Please refer to the release info here https://github.com/Azure/azure-functions-cli/releases/tag/1.0.1

In the next release of Azure Web Apps, we will update the PHP stacks to the latest available versions.
For information on the changes in the new versions, please see the change logs on the PHP website.

Microsoft.NET.Sdk.Functions 1.0.4 has been released.
This release includes updated references to runtime 2.1.0-beta.4 and .NETStandard 2.0 support.

A new version of the Azure Functions Runtime (script host), 1.0.110075 is being deployed.

Please refer to the latest release notes on the release page here for details.

Please use Azure/app-service-announcements-discussions#4 for discussions related to this release.

A new version of the Azure Functions Core Tools has been released. This includes Azure Functions runtime 1.0.11184

Please refer to the release info here https://github.com/Azure/azure-functions-cli/releases/tag/1.0.3

A couple years back, we announced experimental support for building Go (golang) apps via git deployment (i.e. Kudu) on Azure App Service. The usage has been very low, and we are going to deprecate this support in December 2017.

Note that this only applies to the ability to build a Go app in Azure App Service via Kudu deployment. Once deployed, a go app is a self-contained executable, and the removal of the tools will not affect it.

The path forward for Go users is:

• On Windows App Service, you can directly deploy the built Go app as a self-contained exe
• You can also use the new Web App for Containers, which lets use deploy custom Linux Docker containers that can run Go

New Nodejs versions along with relavant NPMs are now available on Azure AppServices to address the vulnerability.

This release includes a variety of changes and fixes, including some minor breaking changes. Most importantly, the Visual Studio setup experience has been significantly improved due in part to several changes included in the final release of Visual Studio 2017 (15.3).

The VS sample project has also been updated to highlight these major changes:

• Durable Functions can be added to any Azure Functions project via a simple NuGet package reference.
• Activity functions can now bind to any JSON-serializeable data type, including primitive types.

Security has also been improved by taking advantage of the new System Keys feature of Azure Functions.

More technical details can be found in the following PR:
Updates for 0.2.2-alpha: Activity binding, System Keys, & improved Visual Studio support

For an overview and detailed documentation of Durable Functions, see our GitHub Docs page: https://azure.github.io/azure-functions-durable-extension/

Release 2.6 (Sprint 6) of the portal is scheduled for Tuesday (7/25). You can try it here https://portal.azure.com/?appsvc.env=stage

Here is the draft release https://github.com/Azure/azure-functions-ux/releases/tag/2.6

App Service still has a few prerelease builds of .NET Core 1.x, which are long deprecated. These will be removed from the VMs starting in mid-October 2017.

Action item: make sure that you upgrade to an official build of .NET Core 1.0 or 1.1.

Please use Azure/app-service-announcements-discussions#7 for discussions relating to this.

Background

VS and VSTS typically use msdeploy (aka WebDeploy) to deploy to Azure Web Apps. They support an 'App Offline' mechanism that takes the app offline during file copying, to avoid 'file in use' issues.

This works by dropping a file called app_offline.htm at the root of the site. The runtime (whether ASP.NET or ASP.NET Core) is then supposed to listen to the creation of the file and shut itself down to unlock the files.

Issue: this can fail if msdeploy doesn't wait long enough

A recent change was made to ASP.NET Core (more specifically AspNetCoreModule) that causes it to take longer in some cases to shut down the Core process after it detects app_offline.htm.

When copying files that are locked, msdeploy has a retry loop, which by default tries 5 times, with a 1 second wait in between. If the file is still locked after that, the deployment fails with ERROR_FILE_IN_USE.

Workaround: increase the retry count

Setting the retry count to 20 instead of 5 should give it plenty of time to shut down. Here is how to do this.

Visual Studio deployment

When deploying from VS, you can do this with a change to your .csproj file. Add this line in the <PropertyGroup>:

<RetryAttemptsForDeployment>20</RetryAttemptsForDeployment>

See here for a full csproj sample with this change.

VSTS deployment

From VSTS, you get control over the underlying msdeploy.exe command line. You can increase the retry count to 20 by setting the -retryAttempts:20 flag. See this page for details on all msdeploy flags.

https://blogs.msdn.microsoft.com/waws/2017/06/28/sitefinity-based-azure-app-service-affected-after-net-framework-4-7-update/

The .NET Framework running on Azure App Service was upgraded to 4.7 (see #2). Unfortunately, it was found that 4.7 can cause issues with some sites running the Sitefinity CMS. The error looks like:

The type initializer for "Telerik.Sitefinity.Security.SecurityManager" threw an exception

If you are in that situation, you can install a hotfix that has been issues by Sitefinity. See http://knowledgebase.progress.com/articles/Article/local-site-suddenly-stopped-working-after-running-the-windows-10-updates for details.

See also this thread for related information.

Apologies for the inconvenience.

Now that Core 2.0 has been release, App Service will remove support for 2.0 preview runtimes and SDK. This will happen starting in early October 2017.

Action item: make sure that you upgrade all your 2.0 Preview apps to the official 2.0 bits.

See also #27 for a similar announcement relating to prerelease Core 1.x bits.

Please use Azure/app-service-announcements-discussions#12 for discussions about this change.

[Originally on MSDN forum]

Azure App Service will get support for .NET 4.7 by the end of June 2017. Please refer to this announcement for more .NET 4.7 specific information.

The rollout is expected to complete by Friday June 30th.

See this post for more info about this Core release.

[Was originally on MSDN forum]

What's changing

As you are likely aware, the ASP.NET Core team has switched from the old project.json/xproj format to the new .csproj format. In Visual Studio 2017, only the new format is supported.

Accordingly, we are deprecating the old format in Azure App Service at the end of May 2017. After that, the Kudu/git engine will no longer be able to build those old projects.

Who is affected

This change affects you if you are deploying using Kudu (git support in App Service), and your project is using project.json or .xproj files. Note that it is the act of building these projects on Azure that will no longer work. If you are building elsewhere, and simply deploying the build artifacts to App Service, you are not affected (but please do make sure you are not targeting a pre-release runtime).

What you need to do

You need to migrate to the csproj format. See https://docs.microsoft.com/en-us/dotnet/articles/core/migration/ for detailed steps.

Until now, App Service had a Preview build of .NET Core 2.0. Now the final 2.0 bits are available and will be deployed.

Please use Azure/app-service-announcements-discussions#6 for any discussion related to this.

Today, we released a new version of the Functions Portal UI. Please see https://github.com/Azure/azure-functions-ux/releases/tag/2.12 for details.

Release 2.4 (Sprint 4) of the portal is scheduled for Monday (6/26). You can try it here https://portal.azure.com/?appsvc.env=stage

Here is the draft release https://github.com/Azure/azure-functions-ux/releases/tag/v2.4

Background

ARRAffinity is a cookie used to affinitize a client to an instance of an Azure Web App. e.g. if an app is scaled out to 10 instances, and a user accesses it from their browser, the ARRAffinity helps keep the user going back to the same app instance, instead of getting a random instance each time. This can be useful for some apps that keep user state in memory.

What is changing

This cookie is meant to be round-tripped back to the server via the browser, but it is not meant to be consumed client side (it is not a meaningful value to the client).

To enforce that the client code cannot access it from Javascript code, it will now have the HttpOnly flag set, which prevents accessing it from the document.cookie collection. See this blog post for a good explanation of why it is good security practice to do this.

Note that in the case of ARRAffinity, there was never a real security hole, since this cookie is not a valuable secret even if stolen. Still, for the sake of defense in depth and preventing something that should not be done, it makes sense to make it HttpOnly (which it should have been from the start).

Who can be affected by this change

The only way you can be affected by this change is if you have client side code that tries to access this cookie. We don't think there are any useful scenarios where this should be done, but be aware that you will no longer see this cookie in the client side cookie list.

How to work around if you really need this

On the server side, you can get the ARRAffinity value in the WEBSITE_INSTANCE_ID environment variable. So you can create a different cookie (e.g. ARRAffinity2) and set it to that value (without making it HttpOnly). Then in your client code, just consume this alternate cookie.

A new version of the Azure Functions runtime (script host), 1.0.11002 is being deployed.

Please refer to the release notes at https://github.com/Azure/azure-webjobs-sdk-script/releases/tag/v1.0.11002 for details.