2007-09-19

Running multiple versions of ASP.NET on the same IIS

When configuring a website to run multiple applications with different versions of ASP.NET there are some issues that needs to be resolved before the applications are running smoothly. The guide below describes the setup for a windows 2003 server.

1. Install the different dotnet framework versions on the server.
When installed you can check the c:\windows\microsoft.net\framework folder and each installed version contains an own folder named vx.x.xxxx. On my server, running
dir c:\WINDOWS\Microsoft.NET\Framework\v*
gives the following output
2007-09-12  08:15    <dir>          v1.1.4322
2007-09-12 08:44 <dir> v2.0.50727
2. Make sure the needed framework is installed in the IIS
Each framework version installs a tool named aspnet_regiis.exe. This tool is used to manipulate the IIS metabase for asp.net registrations and mappings. Depending on which version of the framework the tool is shipped with, there exists different switches that can be used. Run the exe in a command window to see which are supported for your version.
To see which frameworks is installed in the IIS metabase, run the tool with the -lv flags. (Example below)
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727>aspnet_regiis.exe -lv
2.0.50727.0 Valid (Root) C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll
If your needed framework isn't listed, go to the version folder and run the aspnet_regiis.exe with the -ir flag. (the -i flag will also install the framework but will also update the scriptmaps, which we don't want to do (not yet anyway))
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322>aspnet_regiis.exe -ir
Start installing ASP.NET (1.1.4322.0) without registering the scriptmap.
Finished installing ASP.NET (1.1.4322.0) without registering the scriptmap.
Running the -lv again we'll se that we now have two frameworks registered in the IIS metabase.
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322>aspnet_regiis.exe -lv
1.1.4322.0 Valid C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll
2.0.50727.0 Valid (Root) C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll
3. Install the scriptmaps on the web application
In addition to installing the framework in the IIS metabase we need to configure the web application to use the specific framework version.
To see which mappings that are in effect use the -lk flag
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322>aspnet_regiis.exe -lk
W3SVC/ 2.0.50727.832
W3SVC/1/ROOT/ 2.0.50727.832
W3SVC/1/ROOT/Reports/ 2.0.50727.832
W3SVC/1/ROOT/ReportServer/ 2.0.50727.832
W3SVC/3/Root/ 2.0.50727.832
To set the scriptsmaps for a specific application use the -s flag. (here my application is running on the path W3SVC/258083574/root/MyApplication)
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322>aspnet_regiis.exe -s W3SVC/258083574/root/MyApplication
Start registering ASP.NET scriptmap (1.1.4322.0) recursively at W3SVC/258083574/root/MyApplication.
Finished registering ASP.NET scriptmap (1.1.4322.0) recursively at W3SVC/258083574/root/MyApplication.
When installation is successful use the -lk to see the updated mapping
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322>aspnet_regiis.exe -lk
W3SVC/ 2.0.50727.832
W3SVC/1/ROOT/ 2.0.50727.832
W3SVC/1/ROOT/Reports/ 2.0.50727.832
W3SVC/1/ROOT/ReportServer/ 2.0.50727.832
W3SVC/258083574/root/MyApplication/ 1.1.4322.0
W3SVC/3/Root/ 2.0.50727.832
4. Make sure each version uses separate Application pools
A common mistake is to use the same application pool for multiple applications running different versions of the framework. This is not recommended and will most certainly break in time.
So... don't.
Changing application pool settings and creating new ones is done in the mmc tool (Internet Information Services). You don't have to configure the pools, just don't mix applications running on different framework versions.

5. Make sure that WebService extensions allows webpages of the specific version
If you now test your new application and tries to view an aspx page but the server only returns a 404 error, then you need to fix the WebService extension settings.
Locate the Web Service Extensions folder in the mmc tool and Allow the ASP.NET version to execute.

Good luck!

2007-09-10

Sandcastle crashes... code and pre tags

Almost done with the current project release. Continuous server(CCNET) is running,
building - OK,
unit tests - OK,
analyzing - OK,
compiling xml documentation -- Err

Computer says:
Info: BuildAssembler: Building topic T:Sdo.Agent.TypeInstance`1

Unhandled Exception: System.Xml.XmlException: Unexpected end tag. Line 2, position 57.
at System.Xml.XmlTextReaderImpl.Throw(Exception e)
at System.Xml.XmlTextReaderImpl.Throw(String res, String arg)
at System.Xml.XmlTextReaderImpl.Throw(Int32 pos, String res)
at System.Xml.XmlTextReaderImpl.ParseDocumentContent()
at System.Xml.XmlTextReaderImpl.Read()
at System.Xml.XmlLoader.ParsePartialContent(XmlNode parentNode, String innerxmltext, XmlNodeType nt)
at System.Xml.XmlElement.set_InnerXml(String value)
at SandcastleBuilder.Components.CodeBlockComponent.Apply(XmlDocument document, String key)
at Microsoft.Ddue.Tools.BuildAssembler.Apply(IEnumerable`1 manifest)
at Microsoft.Ddue.Tools.BuildAssembler.Apply(String manifestFile)
at Microsoft.Ddue.Tools.BuildAssemblerConsole.Main(String[] args)
Last step completed in 01:09:26.3530


Ok, so I checked the xml documentation for the class for mismatching tags, but couldn't find any.
After a bit of searching I found the following post on the Sandcastle forums.
http://www.codeplex.com/SHFB/Thread/View.aspx?ThreadId=12084

A <pre> tag had snuck into the <code> xml documentation and thats not supported.

Well you always learn something. =)