Wednesday, September 29, 2010

IIS 7.5 – different handling of errors for local vs non-local requests

There are few issues which can be discovered during the migration from IIS 6 to 7.5 (example). One of the issues we’ve been unable to identify for quite some time is connected with “virtual instances” built on top of the url rewriting.

The problem stems from the fact that by default IIS does not handle non-ASP.NET requests using ASP.NET pipeline. This means that while all requests to virtual ASP.NET resources (like http://myhost.com/virtualinstance/theresource.aspx) are handled by ASP.NET (and thus can be rewritten to http://myhost.com/theresource.aspx), all requests to virtual non-ASP.NET resources (like http://myhost.com/virtualinstance/thestyle.css) are not handled by ASP.NET (IIS happily returns 404 since there’s no physical resource under such virtual address).

As I’ve pointed out in the article on virtual instances, our way to overcome this problem was to attach an *.aspx page as a 404 page in the IIS (screenshot taken on IIS 6.0).

This way all requests for non-ASP.NET resources were passed to ASP.NET pipeline as http://myhost.com/ErrorHandler.aspx?404;http://myhost.com/virtualinstance/thestyle.css. This only changes slightly the regular expression you can use to handle “virtual” requests but it’s not a big issue.

Unfortunately, it’s been this trick which turned out to not to work on IIS 7.5. Or, at least, work partially. It turned out that all remote requests were handled correctly, while local requests were handled incorrectly – all “virtual” requests to non-ASP.NET resources were still completely ignored by ASP.NET pipeline. We bravely accepted such behavior for quite some time - business clients send only remote requests so there’s been only an inconvenience for our IT guys who were deploying apps onto a server and trying to quickly verify whether or not the app is running by launching a local browser and pointing it to an app.

But since developers also run & test their applications on their local IISes, they needed a simple solution.

Yes, they could install a virtual machine and send requests between their host machine and the virtual machine (so that all requests would be recognized as remote by IIS).

Another option was to force IIS 7.5 to handle all requests with ASP.NET pipeline:

<system.webServer>
  <modules runAllManagedModulesForAllRequests="true">
     ...
  </modules>
</system.webServer>

but this changes the way ASP.NET sees all virtual requests to non-ASP.NET resources – instead of http://myhost.com/ErrorHandler.aspx?404;http://myhost.com/virtualinstance/thestyle.css you just get http://myhost.com/virtualinstance/thestyle.css. Should IIS be responsible for handling all requests, even to static resources? The question is open but surely, handling all requests with ASP.NET would change the semantics when comparing to IIS 6 so there’s always a chance of some subtle issues and extensive testing would be needed.

Luckily, yet another solution exists. It turns out that the errorMode attribute of the httpErrors section of system.webServer in the web.config which is responsible for storing the mapping of 404 to /ErrorHandler.aspx in IIS 7.5 can be configured in one of three ways:

  • DetailedLocalOnly
  • Detailed
  • Custom

And the problem with IIS 7.5 is that the DetailedLocalOnly is the default setting. This changes the way IIS 7.5 handles errors regarding local requests.

So, to conclude, setting the errorMode to Custom makes the semantics equal for local and remote requests and – to us – also means that the error handling under IIS 7.5 works exactly the same as it did under IIS 6.0.

<system.webServer>
  <httpErrors errorMode="Custom">
    <remove statusCode="404" subStatusCode="-1" />
    <error statusCode="404" prefixLanguageFilePath="" path="/ErrorHandler.aspx" responseMode="ExecuteURL" />
  </httpErrors>
</system.webServer>

Thursday, September 16, 2010

The identity of an application pool in IIS

When creating a new application pool, it’s often convenient to be able to identify the identity the pool is using. The issue arises usually on IIS 7/7.5 where default application pools use identities of a form IIS APPPOOL\identityname. And when you grant access to databases/file system you have to provide the identity name in an exact form.

Usually I tend to use this simple script. Just copy it into a text file, name it test.aspx and point your browser to it. The application pool’s identity name will be presented to you in a clear way.

<%@ Page Language="C#" %>
 
Current user: <%= System.Security.Principal.WindowsIdentity.GetCurrent().Name %>

Friday, September 10, 2010

Easy log4net integration into .NET applications

There are plenty of possibilities to integrate log4net logging into your application. You can declare log4net configuration declaratively or imperatively for the whole project, in each separate assembly or even in each separate class. The pattern I describe below assumes that:

  • you want to have a single and possibly the simplest configuration of the log4net for your whole application
  • you do not want to call explicitely any complicated initialization code
  • you do not want to create loggers explicitely (people tend to do that however it’s rather cumbersome)

The idea is as follows – you create a simple proxy class for the logging purposes. The class will have a static constructor responsible for configuring the log4net and two proxy methods for actual logging. It’s up to you to declare this class in the of your assemblies which is then referenced by other solution assemblies.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using log4net;
using log4net.Config;
 
namespace BusinessLibrary.Common
{
    public class Log
    {
        static Log()
        {
            XmlConfigurator.Configure();
        }
 
        public static ILog For( object LoggedObject )
        {
            if ( LoggedObject != null )
                return For( LoggedObject.GetType() );
            else
                return For( null );
        }
 
        public static ILog For( Type ObjectType )
        {
            if ( ObjectType != null )
                return LogManager.GetLogger( ObjectType.Name );
            else
                return LogManager.GetLogger( string.Empty );
        }
    }
 
}

From now on the only way you log anything is to use the proxy class:

Log.For( this ).Info( "Hello from BusinessClass" );

Then, in the application’s configuration file you provide a single configuration for log4net. I usually delegate the configuration to a separate file so that the web.config/app.config contains only:

<configSections>
    <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net"/>
    ...
</configSections>
<log4net configSource=".\Configuration\log4net.config"/>

and a separate file, located under \Configuration\log4net.config contains the actual configuration:

<?xml version="1.0" standalone="yes"?>
<log4net>
    <appender name="TestLogFileAppender" type="log4net.Appender.RollingFileAppender">
        <file value="c:\000\test.log" />
        <appendToFile value="true" />
        <rollingStyle value="Size" />
        <filter type="log4net.Filter.LevelRangeFilter">
            <acceptOnMatch value="true" />
            <levelMin value="DEBUG" />
            <levelMax value="FATAL" />
        </filter>
        <maxSizeRollBackups value="10" />
        <maximumFileSize value="10MB" />
        <staticLogFileName value="true" />
        <lockingModel type="log4net.Appender.FileAppender+MinimalLock" />
        <layout type="log4net.Layout.PatternLayout">
            <conversionPattern value="%newline%date [%thread] %-5level - %message" />
        </layout>
    </appender>
    <root>
        <level value="ALL" />
        <appender-ref ref="TestLogFileAppender" />
    </root>
</log4net>

(this is only an example configuration)

That’s all. No other code is required to either configure log4net itself or create logging objects. You’ll find an example, consisting of a web application and an auxiliary assembly here.