Wer beispielsweise Url-Rewriting einsetzt und eigene Dateiendungen verwendet und eine Website schonmal auf einen Windows Server 2008 in der 64-Bit-Variante deployed hat, wird es kennen: um auf dem Server korrekt ausgeführt zu werden, müssen die Handler im <system.webServer />-Abschnitt der Web.config auf den 64-Bit-Ordner der .NET-Framework-Installation verweisen. Das geht ganz leicht, in dem man beispielsweise die Zeile
1: <add name="Feed" path="*.feed" verb="*"
2: modules="IsapiModule"
3: scriptProcessor="%windir%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll"
4: resourceType="Unspecified" />
in
1: <add name="Feed" path="*.feed" verb="*"
2: modules="IsapiModule"
3: scriptProcessor="%windir%\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll"
4: resourceType="Unspecified" />
ändert.
Aber was tun, wenn man diese Website im Team entwickelt und nicht alle Team-Mitglieder ein 64-Bit-System nutzen? Dann steht man nämlich vor dem Problem, dass jeweils eine dieser Varianten bei einem der Entwickler lokal nicht funktioniert.
Die Lösung:
Man lässt den Application-Pool lokal im "32-Bit-Modus" laufen, d.h. nutzt die erste Variante. Der lässt sich (übrigens auch für Produktivsysteme, was aber nur selten sinnvoll ist) im IIS-Manager einstellen. Dafür einfach einen Rechtsklick auf den Application-Pool machen, Erweiterte Einstellungen wählen und dann "32-Bit-Anwendungen aktivieren" auf true setzen. Und schon wird beim nächsten Aufruf auch auf dem 64-Bit-Rechner der der erste oben stehende Pfad aufgerufen.
Eine kleine Einstellung mit großer Wirkung - so kann nämlich weiter eine einheitliche Web.config-Datei für alle verwendet und auch im Quellcode-Repository gehalten werden.
