Today I made an attempt to run a WSS-site on ASP.NET 2.0. I wanted to see how complicated it was and if everything kept working as expected.
The site I used is the Endeavour Project Portal. This site is part of the Endeavour .NET software development factory which is a commercial product of my company. It’s a SharePoint-powered portal site which displays reports that are generated by our (daily)build-environment. Technically there are several interesting challenges to overcome:
- The site is based on a custom site definition template-set. This template-set is a copy of the standard STS-set, with some minor customizations. However, the copy of the STS-set was made before SP2 was released, so it doesn’t have the changes that were made to the site definition template-sets in SP2.
- The site uses a ASP.NET web control which was build using the .NET 1.1 framework.
- The site uses a few custom made webparts which have been build using the .NET 1.1 framework.
First thing I did was install the .NET 2.0 Framework on the portal-server. .NET Framework 2.0 is still beta and does not come with WSS SP2. I don’t know if it’s available as a standalone package, but I installed it by installing the Team Foundation Server (TFS) client tools (comes with Visual Studio.NET 2005).
Then I changed the ASP.NET version on my IIS WebSite. There’s a new tab available on which the ASP.NET Framework-version can be selected.
Assuming this was all I need to configure, I navigated to the portal-site to check the results. I got an errormessage saying: “The Windows SharePoint Services virtual server has not been configured for use with ASP.NET 2.0….“. The message also included a link to a knowledge-base article on this subject! I wish MS would do that with ALL errormessages in all their products! 🙂
I followed all steps in the KB-article, which was actually just a single step: running the stsadm-tool with the (undocumented) option ‘upgrade’. This caused a window to appear (I know, it’s not what you expect when running a command-line tool) which stated that SharePoint was updating sites. After that it had made some minor changes to the web.config of the Virtual Server to disable some unsupported features of ASP.NET 2.0.
Now I navigated to the portal site to check the results. And guess what: it worked!! I now had an ASP.NET 2.0 portal-site, using an ASP.NET 1.1 webcontrol and ASP.NET 1.1 webparts and they all worked fine. I even recompiled the webcontrol with .NET 2.0 and it still worked!
I did a final check to see if the most complicated webpart would still be fully functional: I check if the site would still properly display build reports.
… and it did not! The webpart displayed an xslt-errormessage“Expression must evaluate to a node-set.“. The webpart loads the xml-report that have been produced by the build-engine and uses xslt-files to transform them into nice HTML. I know the System.Xml-namespace in the .NET 2.0-framework is much more strict than the 1.1-version, but since the webpart is a 1.1-version, it uses the 1.1-version of the System.Xml-namespace and therefore cannot be causing this problem. However, on of the xslt-files contains some C#-code that uses classes in the System.Xml-namespace and is dynamically compiled at first use. So I assume this is causing the problems.
At this time we decided we would not go through with converting our Endeavour Project Portal-product to .NET 2.0 for our next release of Endeavour (v2.5). We have to ship in a few weeks and our 1.1-version of the portal will do fine on portal sites using ASP.NET 1.1. Customers using a ASP.NET 2.0-site can always create a new virtual server and configure it for ASP.NET 1.1 and install our portal product on that virutal server.
However, in the near future we will have to do the conversion and as a result of this first exercise, I think we can expect a lot of complicated challenges to get things running well.