ASPNET Archives - RuslanY Blog

Azure Web App Deployment Slot Swap with Preview

Some time ago I had a blog post describing how to warm up an Azure Web App during deployment slots swap. In that post I explained the sequence of actions that happens during the swap. One important point in that explanation is that if a site has any app settings or connection strings that are marked as “Slot” then during slot swap those settings are read from target (e.g. Production) slot and applied to the site in the staging slot. That causes the restart of the site’s worker process so that those changes take effect and become visible as process environment variable.

The restart of the worker process is OK for the majority of the swaps. But sometimes it would be useful to pause right after the production settings were applied on the staging slot and before the actual swap of host names happens. Recently Azure Web Apps team has released a “Swap with Preview” feature that supports that use case. That feature will give you a chance to verify that the web site in the staging slot works fine with production settings. Also this will allow you to warm up/initialize the site in any way you want. For example you can generate some load on that site so that its cache is completely pre-populated. After you are satisfied with how the site works in staging slot you can complete the swap so that the site is moved to production slot and starts taking on production traffic. The site’s worker process will not be restarted during that step, which means that the worker process in production slot is exactly what you have tested in staging slot.

To demonstrate how Swap with Preview works I’ve created a site and added a “Slot” setting to it with name “SlotName” and value “Production“. Also I added a “Slot” connection string with value “ProductionConnectionString“.

10 URL Rewriting Tips and Tricks

This post describes some of the tips and tricks that one may find useful when solving URL-based problems for their web server or web site. Each tip/trick has a description of a problem and then an example of how it can be solved with IIS 7 URL Rewrite Module.

1. Add or Remove Trailing Slash

Many web applications use “virtual URLs” – that is the URLs that do not directly map to the file and directory layout on web server’s file system. An example of such application may be an ASP.NET MVC application with URL format similar to this: http://stackoverflow.com/questions/60857/modrewrite-equivalent-for-iis-7-0 or a PHP application with URL format that looks like this: http://ruslany.net/2008/11/url-rewrite-module-release-to-web/. If you try to request these URLs with or without trailing slash you will still get the same page. That is OK for human visitors, but may be a problem for search engine crawlers as well as for web analytics services. Different URLs for the same page may cause crawlers to treat the same page as different pages, thus affecting the page ranking. They will also cause Web Analytics statistics for this page to be split up.

Setup IIS on Server Core – Windows Server 2008 R2

This post has been updated from its original version to correct the installation instructions, which have changed since the time the post was written in Feb 2009.

With the addition of .NET Framework to Server Core in Windows Server 2008 R2 the Server Core installation option became even more appealing for those who want to use a very low footprint server for hosting their applications. Availability of .NET framework provides the following great benefits:

ASP.NET support – you can now use Server Core to host your ASP.NET applications.
IIS Remote Management – Server Core does not provide any user interface other than command line. But if you prefer to use IIS Manager UI to administer IIS, you can now use IIS Remote Manager to connect to IIS on Server Core and perform all the management tasks from within familiar UI of IIS Manager.
PowerShell – Windows Server 2008 R2 includes IIS PowerShell snapin, which is also available on Server Core.

This post describes how to setup and configure IIS on Server Core in Windows Server 2008 R2. Specifically the following tasks are described:

Using oclist and ocsetup commands
Basic Installation of IIS
Installing ASP.NET
Installing PowerShell and IIS snap-in
Enabling IIS Remote Management

ASP.NET postbacks and URL rewriting

ASP.NET Web Forms extensively use postback mechanism in order to maintain the state of the server-side controls on the web page. This makes it somewhat tricky to perform URL rewriting for ASP.NET pages. When a server side form control is added to the web page, ASP.NET will render the response with HTML <form> tag that contains an action attribute pointing back to the page where the form control is. This means that if URL rewriting was used for that page, the action attribute will point back to the rewritten URL, not to the URL that was requested from the browser. This will cause the browser to show rewritten URL any time a postback occurs.

Let me demonstrate this on an example. Assume you have a very simple web form in a file called default.aspx. When you request http://localhost/default.aspx in a browser and then view the HTML source for the response, you will see that the response contains the <form> element, which looks similar to this:

Wildcard script mapping and IIS 7 integrated pipeline

The big benefit of IIS 7 integrated request processing pipeline is the fact that all the nice and useful ASP.NET features can be used for any type of content on your web site; not just for ASP.NET-specific content. For example, ASP.NET SQL-based membership can be used to protect static files and folders. Also, ASP.NET extensibility API’s, such as IHttpHandler and IHttpModule can be used to add custom modules and handlers that would be executed even for non-ASP.NET content.

IIS 6 did not have this level of integration. ASP.NET was plugged into IIS 6 as an ISAPI extension and by default was configured to handle ONLY requests mapped to that extension – for example any request that ended with “.aspx” would be be processed by ASP.NET extension. This obviously was a big limitation for customers who wanted to be able to use ASP.NET features for all other contend on web site. The most common way to workaround that was to use “Wildcard script mapping”. This post explains how an application that used wildcard script mapping in IIS 6 can be migrated over to IIS 7.

Assume you had configured ASP.NET in IIS 6 to handle all requests by using wildcard script mapping. For example you had an ASP.NET module for URL rewriting and you wanted this module to handle extension-less URLs.