This white paper describes features that are included in Microsoft® SharePoint® Portal Server 2003 Service Pack 2 (SP2) and Microsoft Windows® SharePoint Services Service Pack 2 (SP2). It also provides best practices and guidance about how you can architect your solutions considering the current and future versions of SharePoint Products and Technologies.

Four new enhancements are being delivered in late 2005 for SharePoint Products and Technologies. Not all enhancements apply to both Windows SharePoint Services and SharePoint Portal Server, as illustrated in the following table.

In this article

Support for Windows Server 64-bit versions

Support for SQL Server 2005

Extranet support

Support for .NET Framework 2.0, ASP.NET 2.0, and Visual Studio® 2005

Support for Windows Server 64-bit versions

Windows SharePoint Services 2.0 SP2 and SharePoint Portal Server 2003 SP2 now support being run in WOW64 (32-bit emulation) mode on 64-bit versions of Windows. Neither product currently supports running as a native 64-bit application. For more information about enabling SharePoint Portal Server with SP2 on an x64-based server, see The prerequisites that are required to install SharePoint Portal Server 2003 SP2 on a computer that is running Windows Server 2003 x64 Edition.

There are no performance improvements for SharePoint Products and Technologies when running in WOW64 mode on 64-bit versions of Windows. However, other applications and the operating system might be able to take advantage of the 64-bit server functionality.

Note   If you have other applications hosted on Internet Information Services (IIS), they will run in 32-bit emulation mode also. This is because enabling 32-bit applications in IIS on a 64-bit server is IIS-specific, not Web application–specific. For information about configuring IIS for 32-bit emulation mode, see Preparing Front-End Web Servers for Windows SharePoint Services.

Top of Page

Support for SQL Server 2005

Microsoft SQL Server 2005 includes features such as extended XML support and integrated CLR support. Windows SharePoint Services version 2.0 and SharePoint Portal Server 2003 do not take advantage of that new functionality; however, there are general benefits to upgrading to SQL Server 2005, such as better performance.

SharePoint Portal Server and Windows SharePoint Services work equally well with either SQL Server 2000 or SQL Server 2005. SQL Server 2005 does not enable any new SharePoint Products and Technologies development scenarios. However, SQL Server 2005 does provide an improvement in performance, and SP2 enables Windows SharePoint Services to run with SQL Server 2005. How much performance improvement you can expect depends on the usage patterns of your users.

Top of Page

Extranet support

In Windows SharePoint Services and SharePoint Portal Server, some of the hyperlinks within Web pages and e-mail messages are absolute URLs. Earlier releases of Windows SharePoint Services generated those absolute URLs by using the protocol scheme, host, and port of the Web request that Windows SharePoint Services received, or by using the base URL of the site. This functionality can prevent Windows SharePoint Services from supporting certain advanced extranet scenarios, where a reverse proxy server is deployed in front of the server running Windows SharePoint Services. Windows SharePoint Services with SP2 provides support for three previously unsupported configurations:

• SSL termination In this configuration, the user accesses a SharePoint site by using SSL (Secure Sockets Layer), with a URL prefix of https://. A reverse proxy server receives that request and converts it into an HTTP request, then forwards the request to the server running on SharePoint Products and Technologies. Because of the reverse proxy, Windows SharePoint Services or SharePoint Portal Server receives a non-SSL request (HTTP) instead a secured SSL request (HTTPS), and therefore it generates an HTTP:// response instead of a secured HTTPS:// response. This kind of scenario is usually used when it's required that the connection between a user and the network be encrypted, but the server running Windows SharePoint Services doesn't necessarily support SSL encryption.
• Host header modification In host header configuration, the user accesses a SharePoint site by using — for example — the URL http://www.contoso.com, where the host is www.contoso.com. A server with reverse proxy receives that request, then changes the host header to the internal name of the server (for example, internal.contoso.com) and forwards the request to the server running Windows SharePoint Services. Because the server receives the request with a modified host header, it generates hyperlinks by using that modified host header with the URL (for example, http://internal.contoso.com), which is wrong from the client's perspective.
• Port translation In port translation, the user accesses a SharePoint site by using a particular port number, for example port 80 for HTTP requests. A reverse proxy server receives the request and forwards it to the server running Windows SharePoint Services on a different port, such as port 81. Because Windows SharePoint Services or SharePoint Portal Server receives the request on port 81, it will generate a hyperlink that has a port number such as http://www.contoso.com:81/, which refers to the server incorrectly from the client's perspective.

After installing SP2, you can define URLs for the incoming requests and outgoing URLs.

Note   SP2 supports the advanced extranet configurations listed above only if Windows SharePoint Services with SP2 and SharePoint Portal Server with SP2 are deployed in non-scalable hosting mode.

For more information about how to set up advanced extranet scenarios, see Overview: Windows SharePoint Services 2.0 SP2 Beta in Windows Server 2003 R2.

Top of Page

Support for .NET Framework 2.0, ASP.NET 2.0, and Visual Studio® 2005

Windows SharePoint Services with SP2 supports running on the Microsoft .NET Framework 2.0, which includes ASP.NET 2.0. Note that SharePoint Portal Server, on the other hand, will not support .NET Framework 2.0, even with SP2. The next major releases of both Windows SharePoint Services and SharePoint Portal Server will both be based on, and hence make extensive use of, ASP.NET 2.0 and its multitude of new features.

From a developer's perspective, Windows SharePoint Services with SP2 simply runs on the new CLR. Windows SharePoint Services has not been redesigned to take advantage of any of the new major features of ASP.NET 2.0, such as Master Pages and the Web Part Framework. However, the new class libraries are certainly available to custom Web Parts, pages, event handlers, and so on.

There are two supported scenarios in which you can create your Windows SharePoint Services implementation with support for .NET Framework 2.0:

• Side-by-side installation of .NET Framework versions 1.1 and 2.0  You can install Windows SharePoint Services on a server on which .NET Framework version 1.1 and version 2.0 are both installed. If you plan to eventually install SharePoint Portal Server on this server, do not install .NET Framework 2.0.
  Additionally, you can also run ASP.NET 1.1 and ASP.NET 2.0 side by side on different Microsoft Internet Information Services (IIS) Web applications that are running Windows SharePoint Services with SP2. In this scenario, you can create custom extensions to Windows SharePoint Services that leverage the new features of .NET Framework 2.0, such as custom administrative tools.
• Installation of .NET Framework version 2.0 only  In this scenario, Windows SharePoint Services runs with .NET Framework 2.0, and .NET Framework 1.1 is not installed. However, running Windows SharePoint Services with .NET Framework 2.0 still provides the same features and functionality as running Windows SharePoint Services with .NET Framework 1.1.
  In some cases, ASP.NET 2.0 enhanced its security by locking down operations that were possible in ASP.NET 1.1. Some of these lockdowns are incompatible with Windows SharePoint Services and must be disabled for the application to function correctly. For more information about how to configure Windows SharePoint Services to support .NET Framework version 2.0, see Overview: Windows SharePoint Services 2.0 SP2 Beta in Windows Server 2003 R2.

Running .NET Framework 1.1

It is not required that you upgrade any Windows SharePoint Services 2.0 installations to ASP.NET 2.0. Support for ASP.NET 2.0 is provided to accommodate users who want to update their computers with the latest version of .NET Framework, or leverage development improvements in the new version of ASP.NET.

Upgrading to .NET Framework 2.0

Although it is not required that you upgrade to ASP.NET 2.0, there are many improvements to the development platform and environment in that release of the framework. The Windows SharePoint Services 2.0 object model and SOAP services are fully supported for use in ASP.NET 2.0 applications.

To leverage ASP.NET 2.0 Web Parts in Windows SharePoint Services, a wrapper Web Part must be written to make the ASP.NET 2.0 Web Part appear to be a Windows SharePoint Services Web Part. After this is done, your ASP.NET 2.0 Web Part should function normally within your Windows SharePoint Services pages. Wrapper Web Parts will not be required in the next version of Windows SharePoint Services or the next version of SharePoint Portal Server (code named Office "12" SharePoint Servers), which both natively support ASP.NET 2.0.

In most SharePoint Portal Server installations, it is better to continue to use the current technologies that are supported natively in the product — that is, ASP.NET 1.0 and .NET Framework 1.1 — rather than mixing the platforms.

Implications for Web Part development and deployment

The following set of frequently asked questions is taken from the SharePoint Thoughts blog, and provides a good set of answers to what we suspect will be the most commonly considered ways of exploiting this new development:

With Windows SharePoint Services with SP2, will the SharePoint worker process run in ASP.NET 2.0?
Yes, it can. Alternatively, you are not forced to use ASP.NET version 2.0.

What is the advantage of running my virtual server in ASP.NET v2.0?
After you're running in the ASP.NET version 2.0 space, the corresponding CLR libraries are available. Your code will be able to take advantage of new features in addition to the security and performance enhancements found in the new runtime.

If my my virtual server continues to run in ASP.NET 1.1, can my code call another assembly that was compiled in .NET v2.0?
No. CLR fundamentals state that you can't "upstream" the CLR version from the current running version. In other words, if you decide to run with version 1.1, you are limited to loading and working with assemblies compiled with version 1.1 or earlier.

If my virtual server runs in ASP.NET 2.0, will my Web Part code need to be recompiled?
No. This is basically the reverse scenario of the last question, but the answer is not the same. "Downstream" is possible; therefore, any existing 1.x compiled assemblies should continue to work.

Can I create a virtual server/directory that runs in ASP.NET 2.0 and have my SharePoint site running under ASP.NET 1.1 call into the pages and Web services exposed by the ASP.NET 2.0 site?
Yes.

Can I use ASP.NET 2.0 Web Parts on Windows SharePoint Services with SP2?
Not as Web Parts. Given that all Web Parts can be treated as standard Web Form controls, ASP.NET 2.0 Web Parts can be added to pages running in Windows SharePoint Services with SP2, just not within Web Part zones. In this manner, such Web Parts will behave no differently than standard Web Form controls, and should have been written with this contingency in mind. Out of the box, Windows SharePoint Services will not use any ASP.NET 2.0 constructs. At the core level, SP2 will not change the rendering behavior of Windows SharePoint Services. In other words, Windows SharePoint Services will not suddenly gain the ability to use master pages or ASP.NET 2.0 Web Parts. Until the next major release, your only course of action is to take an approach of encapsulating an ASP.NET 2.0 Web Part with a Windows SharePoint Services Web Part designed for this purpose. You might want to investigate http://www.smartpart.info for an example of this technique.

Can I use Visual Studio 2005 to compile my Windows SharePoint Services Web Parts?
Visual Studio 2005 is bound to the 2.0 runtime; therefore, the answer is yes if you are using SP2; otherwise, the answer is no.

Will I need to specify assembly redirection or runtime information for my Web Part assemblies?
No.

Will I need to specify assembly redirection or runtime information anywhere else?
Yes. If you want to deploy Web Part packages that contain CLR version 2.0 compiled Web Part assemblies (that is, SharePoint Web Parts compiled by using the new CLR), you will need to create a *.config file for stsadm.exe that specifies the following:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup>
<supportedRuntime version="v2.0.50727" /> <!-- update the version # once .Net v2.0 is released -->
<supportedRuntime version="v1.1.4322" /> <!-- this is the version number for .Net v1.1 -->
</startup>
</configuration>

The config file (appropriately named stsadm.exe.config) will need to be placed next to stsadm.exe. If you don't add the config file, you will get the error message, "Version 1.1 is not a compatible version."

Top of Page