The Windows Azure Web Sites (WAWS) team passionately invests in a support model for development stacks that allows your web apps to start running quickly and gives your web apps room to grow. This blog article captures a few basic principles we use for versioning and extensibility of development stacks and how these principles apply to your web apps.

We currently support .NET, PHP, Node.js, and Python stacks. The Windows Azure development center at https://azure.microsoft.com/en-us/develop provides a great knowledge base for each of these. Once you create a website you can just upload your content and we will get it running with minimal information input from you.

WAWS Development Stacks Versioning

Some development stacks we support such as PHP are designed to enable side by side versions. For these development stacks we provide a set of current versions that have been validated for our platform. We also establish a default so no input is required unless you prefer a specific version for compatibility reasons.

Other development stacks such as .NET are designed to provide in-place upgrade of some versions (e.g. .NET 4.5). In this case we work hard to maintain a current view of the development stack and provide you with the features and benefits of the latest versions.

A summary of versions available with WAWS for each supported development stack and the respective version defaults is available at this link: https://github.com/projectkudu/kudu/wiki/Azure-Web-Sites-Development-Stacks.

Development Stacks Extensibility

We support extensibility points provided by each development stack in case you may need to customize.

.NET

The .NET framework is deeply integrated with the WAWS platform.

Configuration

Configuration can be specified using the web.config file. The apphost.config file some developers may be accustomed to using is not directly editable with WAWS, but it can be modified by using XML Document Transformation (XDT) declarations. Some settings in apphost.config such as default documents are also available to edit in the web site’s CONFIGURE tab via Azure portal.

Extensibility

Bin-deployable components like MVC or Web Pages can be added to your web application folder.

Node.js

Configuration

The following are the main configuration files relevant for a Node.js application deployed on WAWS:

• package.json

This is a Node.js specific configuration file that is relevant cross-platform. Example usages include specifying Node.js module dependencies (such as Express.js), and the runtime version number.

• iisnode.yml

This is a configuration file used by the iisnode custom IIS modules specific. Example usages include specifying the command for starting node.exe, the number of node.exe processes that iisnode will create, and logging configuration.

• web.config

This is an IIS configuration file used by the WAWS platform. This file captures the required handler registration, and allows the use of URL rewriting for performance optimization of static files use.

Extensibility

The Node.js development stack integrated with WAWS includes the core functionality documented at https://nodejs.org/api. The ecosystem of NPM modules documented at https://npmjs.org is available to extend core development stack functionality. The package.json configuration file can be used to specify modules to include with your web application. When using the git-based source control integrated with the WAWS platform npm install runs during the git push operation to fetch and install dependencies. When using other deployment mechanisms such as FTP you can download and configure modules during local development and upload the entire web app to WAWS. Keep in mind that NPM modules include both Javascript modules which are compatible cross-platform, and native modules that may be designed to target a particular platform – it is always a good idea to test your application.

Runtime Version

You can select any of the Node.js versions included with the WAWS platform, or you can upload and configure a custom Node.js runtime. Instructions are available via Windows Azure Developer Center at https://azure.microsoft.com/en-us/develop/nodejs/common-tasks/specifying-a-node-version.

PHP

Configuration

The main configuration file relevant for a PHP application deployed on WAWS is the standard PHP .user.ini file. This file can be used to set changeable PHP directives such as display_errors for diagnostic.

Extensibility

WAWS supports a set of core PECL extensions by default. We also welcome custom extensions. To enable a custom extension bring the DLL under the FTP root and add a PHP_EXTENSIONS app setting under the CONFIGURE tab with the value set to the location (relative to your application root) of your PHP extensions.

Runtime Version and Customization

Version selection is available on access to the website’s CONFIGURE tab via the Azure portal.

Custom FastCGI-based PHP development stacks are also supported with WAWS. Upload a development stack under the website root. Access the CONFIGURE tab of the website and associate the new script processor (usually php-cgi.exe) with the *.php extension. An absolute path is needed for the script processor: e.g. D:homesitewwwrootphp5.5php-cgi.exe where D:homesitewwwroot is used to refer to the site root.

Python

Configuration

The main configuration file relevant for a Python application deployed on WAWS is web.config. This file captures the required handler registration, and allows the use of URL rewriting for performance optimization of static files use. The use of a web.config file is optional, handler mappings can also be specified via the CONFIGURE tab in the Azure portal. More information is available via Windows Azure Developer Center at https://azure.microsoft.com/en-us/develop/python/tutorials/web-sites-configuration.

Some configuration options can be updated via App Settings under the same CONFIGURE tab in the Azure portal:

• WSGI_LOG: absolute path to log file for capturing application and config errors
• WSGI_HANDLER: callable application object for the WSGI protocol accepting an environment and start_response function

The value specified here needs to be a module/package name, followed by the attribute in the module to be used – e.g. mypackage.mymodule.handler (add parenthesis to indicate that the attribute should be called).

• WSGI_RESTART_FILE_REGEX: regular expression to specify file names

By default this refers to all *.py and *.config files: .*((.py)|(.config))$

Extensibility

You can add packages to your deployment by including under application root and configuring the PYTHONPATH via web.config or App Settings. Virtualenv is not currently supported with WAWS.

To support deployment of arbitrary packages first create a directory for storing the packages under website root.  This is similar to having a site–packages directory in your Python lib folder, but it is located within your web application and is deployed to Windows Azure Websites.  Copy packages to this new directory, and add the absolute path to this directory to PYTHONPATH in web.config (e.g. D:homesitewwwrootmy-packages).  Now the packages will be available for importing from within the web application.

One example of this would be including Django within your application.  You would first download or install Django into an existing Python installation.  Next you would copy the Django package (typically a folder called django with an __init__.py file in it) into a directory in your application.  By default your application root is included in the list of directories searched for packages.  If you’d like to include it in a subdirectory (for example mypackagesdjango) you can add the parent directory to PYTHONPATH in web.config – in this case it would be D:homesitewwwrootmypackages.

More information is available via Windows Azure Developer Center at https://azure.microsoft.com/en-us/develop/python/tutorials/web-sites-with-django.

Runtime Version and Customization

We welcome custom FastCGI-based Python development stacks. You can upload your custom development stack under the website root and configure the website handler mapping to include the absolute path to your FastCGI based script processor.

We always appreciate feedback, let us know how to better support your development stacks needs via Forums Feedback.