A new Platform

On April 24, 2026 Microsoft Windows Server 2003 and Visual Studio .NET 2003 are officially released. Many developers and beta testers (myself included) have been feverishly working with late - beta releases of these products in an effort to be prepared to move forward and understand the important issues and changes that can directly affect our economic futures,and those of our clients, in working with these product.

First, lets put this whole thing in perspective. About 1997, the internal development teams in Microsoft began to have a kind of "epiphany". We had XML coming on the scene in a big way, standards compliance was becoming more the rule than the exception, and there was considerable effort to come out with a solution to "DLL Hell". Earlier efforts at an integrated "codebehind" event - driven web development model had already been experimented with in the form of WebClasses with VB 6.0. The gurus at Microsoft learned a lot from this, and at the same time, they were dealing with the JAVA space and making attempts to integrate all the lessons learned into an entirely new vision of a platform that would be extensible, strongly typed, allow for future extensions with XML integration, and provide for new standards such as SOAP and webservices, XSLT, and other enterprise solutions that would not only improve Microsoft's dominance in the development and OS space, but also provide the platform for strong new innovations.

What emerged over the period from about 2000 through the present from these efforts was SOAP, Webservices, the .NET platform and the C# and VB.NET languages, XML support in SQL Server, Biztalk, and most importantly, the concept of the Common Language Runtime, an effort spearheaded by Anders Hejlsberg and his development team. I was one of the 14,000 developers at the Professional Developers Conference in July 2000 who received the first 6 CD distribution of Visual Studio.NET BETA 1, and I immediately recognized they had come up with something very important. I've been "hooked" on .NET ever since, and as far as I am concerned, everything else that has evolved since then is history in the making. There have certainly been bumps along the road. Having said that, however, I can confidently state that my early decision to embrace the .NET platform and Microsoft's brand of solutions in particular, has been a profitable one. SUN, to some extent, and IBM to an even greater extent, have supported moving into the future of standards compliance with equally exciting innovations and toolkits.

The .NET Framework team has laid down its policy as being committed to compatibility from version to version., and states that the majority of applications built against the .NET Framework version 1.0 should execute flawlessly on version 1.1 and future releases. This is good news for us as developers, but we also have a number of issues we'll need to begin dealing with immediately. This article summarizes what I think are some of the most important of these issues, and attempts to simplify and make more easily "digestible" the volumes of information that seem to always accompany these new releases. In particular, we have two birds to kill here, because not only do we have a new version of .NET to deal with, we have a whole new operating system in Windows Server 2003 to go with it.

Typically, platform vendors forced users to upgrade to the latest version shipped. Software developers programming for that platform were responsible for resolving any resulting incompatibilities. With 2003, The .NET Framework team has provided us with a technology called side-by-side execution. The main difference between the old Visual Basic model and the side-by-side execution approach for the .NET Framework is that with the old Visual Basic model an application could be upgraded to run with the new runtime only if a developer recompiled the application using the newer toolset. In the case of side-by-side execution, we now have the power to upgrade an application simply by modifying the application's configuration file. Basically, side-by-side execution enables multiple versions of the .NET Framework to be present on a system and execute concurrently without interfering with each other. That's a big plus for us as developers and system administrators. What I've done here is attempt to distill the majority of the important considerations at hand from the various Microsoft documents relating to these issues, and present them in condensed, concise form in a single article. I've also included some specific information for webmasters about ASP.NET configuration with version 1.1 of the framework under the "Configuring ASP.NET Web Applications" topic below.

To get a "developer - oriented" handle on the challenges at hand, let's try to simplify the expected behavior of the platform under different scenarios:

Windows Services, Windows Forms, and Console Applications

The default upgrade behavior for Windows Services, Windows Forms, and console applications that are installed locally is as follows:

* If you install a version 1.0 application on a system with only version 1.1 of the .NET Framework present, it will try to run against version 1.1 unless this behavior is specifically disallowed.

* If you install a version 1.0 application on a system with both 1.1 and 1.0 of the Framework, it will run against 1.0 unless this behavior has been specifically disallowed.

* If you install a version 1.1 application on a system with both 1.1 and 1.0 of the Framework, it will run against 1.1 unless specifically changed.

* If you install a version 1.1 application on a system with only 1.0 it will not run unless the behavior is specifically configured to be changed.

You can override the default behavior by simply adding XML tags to the relevant application's configuration file ( ApplicationName.Exe.config) , creating that file if it does not already exist. You can find specific guidance on and examples of this behavior, along with behavior and scenarios for ASP.NET applications, COM interop, and Microsoft Internet Explorer hosting scenarios (such as no-touch deployment and Windows Forms controls embedded in a Web page), COM+ scenarios, and dynamic-link libraries (DLLs) in the product documentation and in the "Side-by-Side Execution of the .NET Framework" topic in the MSDN Library.

Versioning Considerations:

Visual Studio .NET 2003 produces code that executes on the .NET Framework version 1.1. Visual Studio .NET 2002 produces code that executes on the .NET Framework version 1.0. Each version of Visual Studio targets only the version of the .NET Framework with which it shipped. You cannot, for example, install .NET Framework 1.1 and expect Visual Studio.NET 2002 to compile against it.

Neither tool provides the ability to target other versions. When a project created with Visual Studio .NET 2002 is opened in Visual Studio .NET 2003, the tool will offer to upgrade the project automatically to the .NET Framework version 1.1. While Microsoft states that this situation is "irreversible", this is generally far from the truth. In most cases, the class files (.cs or .vb extensions, and others) will compile perfectly under both versions. In fact, by simply modifying some minor metadata in solution (.sln) and project (.csproj or .vbproj) files, it is possible to easily interchange between 2002 and 2003 versions of Visual Studio.Net projects and solutions. There is at least one tool that does this, and developers will certainly be releasing new and better tools to promote more ease of interoperability between the 1.0 and 1.1 (2003) versions of the .NET platform.

The basic steps to "backwards convert" a Visual Studio.NET 2003 solution so that it can be reloaded and compiled by Visual Stuidio.NET 2002 is as follows:

1) In SLN files, the 8.0 must be replaced with 7.0.
2) In vcproj files (only vcproj), the 7.10 part must be replaced by 7.0.
3) In VB.NET and C# project files, 7.10.xxxx is replaced with 7.0.9466, where xxxx is the build number of VS.NET 7.1
4) In VB.NET and C# projects, the schema version 2.0 should be replaced with 1.0.
5) In RESX files, the types declared are 1.0.5000 and should be replaced with 1.0.3300.
6) In RESX files the base-64 encoded part that describes the version of the stream must change from LjAuNTAw to      LjAuMzMw (base-64-encoded versions of 1.0.5000 and 1.0.3300).


Applications built with the .NET Framework using Visual Studio .NET 2002 and Visual Studio .NET 2003 will benefit from side-by-side execution. Both versions of Visual Studio .NET can be installed and execute on the same machine simultaneously for those developers who choose to support solutions on both versions of the .NET Framework.

Compatibility Information:

The 1.1 Framework is designed to be highly compatible with the 1.0 Framework. The vast majority of applications built on the 1.0 Framework will continue to operate on the 1.1 Framework.

Breaking Compatibility:

There are certain cases where the development team found it absolutely necessary to break compatibility. The complete list of breaking changes for the 1.1 Framework can be found at http://www.gotdotnet.com/team/changeinfo/Backwards1.0to1.1/default.aspx.

Despite the high degree of compatibility between the 1.0 and 1.1 Framework, most applications that use the 1.0 Framework are not automatically upgraded when the 1.1 Framework is installed. Installing the newer versions of the .NET Framework does not affect most types of existing applications in any way. The 1.1 Framework is designed so that it can be installed or uninstalled from a system with no impact on applications that are using the 1.0 Framework. Similarly, applications built with the 1.1 version of the Framework are not affected when the older Framework is installed. However, uninstalling an older version of the Framework can affect existing applications that depended on that version and are not perfectly compatible with the newer version.

Side-by-side execution gives application developers and systems administrators the ability to configure existing applications to use the newer version of the Framework. Applications can be tested with the new version of the Framework and configured to work with the new version when you decide it is appropriate. In the rare event that your application does not work on the 1.1 Framework, it can be configured to only support the 1.0 Framework.

However, allowing 1.1 applications to execute in the version 1.0 Framework is much more difficult. Applications that use features that are only found in the 1.1 Framework will not operate in the 1.0 Framework. You can find a list of these features at http://www.gotdotnet.com/team/changeinfo/Forwards1.0to1.1/default.aspx.

How to Configure Your Application:

The method of application configuration required varies depending on the type of application being built. Windows Forms, console applications, and Windows services are configured with an application configuration file. Web applications (ASP.NET and XML Web services) are configured through the Internet Information Services (IIS) administrator, normally by selecting the appropriate ISAPI filter for ASP.NET.

Configuring Windows Client Applications

You can test or permanently redirect 1.0 Windows client applications to the 1.1 Framework by providing an application configuration (XXX.exe.config) file. The application configuration file can direct the CLR to load a specific version of the .NET Framework into the application's process. The version of the Framework that is loaded at run time can differ from the version with which the application was actually compiled.

The supportedRuntime element affects the choice of the Framework version. The startup section can contain one or more supportedRuntime elements,and each element specifies a version of the Framework that the application supports. The supportedRuntime elements are ordered by preference.The most preferred version of the Framework is listed first. For example, an application that supports both the 1.0 and 1.1 Framework but prefers to use 1.1 Framework would have the following in the startup section of the application configuration file:

<configuration>
…
<startup>
<supportedRuntime version="v1.1.4322" />
<supportedRuntime version="v1.0.3705" />
</startup>
…
</configuration>

The version number specified in the supportedRuntime element must match the subdirectory where the Framework installed. For example, the version 1.0 Framework is installed in the directory C:\Windows\Microsoft.Net\Framework\v1.0.3705, so the version number specified in the configuration file would be "v1.0.3705".The 1.1 Framework is installed in the C:\Windows\Microsoft.Net\Framework\v1.1.4322 directory. Wildcards are not allowed in the supported runtime version number, so an application cannot be configured to support a version of the Framework that has not yet been released.

The CLR determines which version of the Framework to load based on the versions listed in the application's .config file and the versions that are available on the system. The configuration can be modified at any time either before or after the application is deployed.

Unconfigured Windows Client Applications:

Applications that do not carry a configuration file or at least the supportedRuntime element in their configuration files execute with the version of the Framework that was used to build the application (if it is present). When that version of the Framework is not available, the CLR uses a later version of the Framework in its place. When no suitable version of the Framework is found to execute an application, the CLR displays a dialog box which lists the versions of the Framework that the application supports and asks the user to install one of the listed versions. This dialog can be suppressed by the setting the NoGuiFromShim key in the registry:

HKLM\\Software\\Microsoft\\.NETFramework\\NoGuiFromShim = 1

Unmanaged Application Configuration:

Many unmanaged Windows client applications use the services of managed components (components built using the .NET Framework) through COM Interop. Hosting a managed component on a Web page viewed within Internet Explorer is an example of an unmanaged application (Internet Explorer) using the services of a managed component. Managed Windows client applications deployed to the desktop through "no-touch deployment" with Internet Explorer is another example. The unmanaged host applications can be configured to use a specific version of the Framework for their managed components. By default, when the components are loaded by an unmanaged application, the managed component is loaded along with the newest available version of the Framework into the application's process. This behavior is somewhat different from the behavior of managed Windows client applications previously described. Unlike a fully managed application, unmanaged .exe files lack the information in the header that describes the version of the Framework the code was built with and this leaves the CLR with only the choice of loading the latest available version of the Framework.

However, when a component requires a very specific version of the Framework, a configuration file like the one previously described can be provided for the unmanaged .exe (Internet Explorer, for example) that hosts the component. Note that the configuration file must exist for the .exe that hosts the component (IExplore.exe), not for the managed component itself. Ultimately, this means all managed components called by a particular unmanaged application run on the same version of the Framework, either the latest available version or the one designated in the application's .config file. These configuration files can be created from scratch using the XML example previously shown. The .config files should be named in the same manner: [Unmanaged App Exe Name] .exe.config (e.g., iexplore.exe.config).

Configuring ASP.NET Web Applications:

Web servers can be configured to use separate versions of the .NET Framework for each individual Web site built using the .NET Framework (i.e., the ASP.NET libraries). All code executing within a given site uses the version specified for that site or for the server if a version is not specified for the site.

Rather than using configuration files to choose the Framework version, the configuration for each site is set within the IIS Administrative Console by selecting the specific versions of the ASP.NET ISAPI filter. The ASP.NET filter is set in the ISAPI Filter tab of the Web Site Properties dialog. The filter can be set for each individual site. It can also be set for the entire Web server by changing the filter at the root Web site level. The ASP.NET filter is implemented in the file aspnet_filter.dll. The 1.0 filter is located in the %windir%\Microsoft.Net\Frameworks\v1.0.3705 directory, and the 1.1 filter is located in the %windir%\Microsoft.Net\Frameworks\v1.1.4322 directory.

Installing the version 1.1 Framework automatically adds the 1.1 ASP.NET filter to the filter list on the Web server's root Web site. Updating the filter at the root level causes all sites that are not individually configured to start using the 1.1 version of the Framework. Any site that needs to continue to use the 1.0 Frameworks needs to be individually configured to use the 1.0 ISAPI filter. The configuration of the ISAPI filter can only be at the Web site level. Individual VRoots cannot be configured to use a different ISAPI filter. This makes upgrading to ASP.NET version 1.1 extremely easy and almost effortless for webmasters who may have been concerned about how and when to upgrade and take advantage of the increased speed, scalability and numerous bug-fixes incorporated into the .NET 1.1 Framework.

Now, to make the above perfectly clear: If you simply install the .NET framework 1.1 redistributable (dotnetfx.exe) on your webserver, it will automatically be configured to use the new 1.1 Isapi filter and ALL of your ASP.NET 1.0 web applications and webservices will automatically run under the 1.1 Framework, which is not only faster and more robust, but more "bug free". I have already tested this on Windows 2000 Server Enterprise and confirmed it to be true. The name of the Version 1.1 filter is "ASP.NET_1.1.4322.573"  and its location is normally at:   C:\WINNT\Microsoft.NET\Framework\v1.1.4322\aspnet_filter.dll

More Information about ASP.NET Deployment

Installing .NET Framework Version 1.1

Installing version 1.1 of the .NET Framework will create a separate installation folder, such as C:\%windir%\Microsoft.Net\Framework\v1.1.0.0. Even after installing an updated version of the .NET Framework, executable applications (NOT ASP.NET web applications) will continue to use the original version with which they are compiled. Because each application's manifest contains the version numbers for the .NET Framework classes that the application uses, the common language runtime can determine which version it should use. They will not use the updated .NET Framework unless explicitly instructed to do so. For example, when you install version 1.1 of .NET Framework, non-ASP.NET applications built with version 1.0 of the .NET Framework will, by default, continue to use version 1.0 components. Version 1.1 of the .NET Framework is included with Windows Server 2003.

However, ASP.NET applications will be upgraded to use the new version of the .NET Framework, unless the /noaspupgrade switch is used with dotnetfx.exe. ASP.NET applications you distribute that include the redistributable installer should use the /noaspupgrade switch to prevent other applications on the computer from being upgraded unintentionally. Administrators can use the command-line aspnet_regiis.exe utility to specify which version of the .NET Framework should be used for an ASP.NET application. There is a different version of aspnet_regiis.exe for each version of the .NET Framework (the utility was included in version 1.0 but largely undocumented). Use version 1.0 of aspnet_regiis.exe to force an application to use version 1.0 of the .NET Framework. Use version 1.1 of aspnet_regiis.exe to force an application to use version 1.1 of the .NET Framework

ASP.NET Version Control

ASPNET_REGIIS.EXE Parameters and Options
The aspnet_regiis.exe utility includes a number of flags to control its operation:

Directories
Use the -s flag for recursive changes to a folder. This flag allows an application and all sub-applications underneath it to be recursively configured to use a specific version of the .NET Framework.
Use the -sn switch to configure an application without affecting sub-applications beneath it (that is, non-recursive).
Use <vdir> to specify a virtual directory as an argument (see <vroot> and <path>).

Component listings
The -lk flag tells which applications use which version of each component.
The -lv flag prints out currently installed versions of ASP.NET components.

Installation flags
The -i flag installs ASP.NET and upgrades previous versions to this version. Use the -i option to reset mapping for the IIS server if the IIS server was installed after the .NET Framework.

The -ir flag is new in version 1.1 and installs ASP.NET without upgrading existing applications (the "r" in -ir is for "redistributable"). Third-party applications should use the dotnetfx.exe /c:"install /noaspupgrade" option when installing the .NET Framework, which is equivalent to the -ir flag for aspnet_regiis.exe. Using the /noaspupgrade switch is important for all third-party application that redistributes the .NET Framework, not just those that require ASP.NET. A client application that redistributes the .NET Framework can cause unwanted upgrades of ASP.NET applications if the installer fails to use the /noaspupgrade switch.

Understanding Changes from one Version of .NET to Another:

Breaking Changes
A breaking change is either a binary or behavioral change to types or members in the .NET Framework that makes an application backward or forward incompatible. A backward breaking change makes an application written for the .NET Framework version 1.0 execute improperly on version 1.1, while a forward breaking change makes an application written for the .NET Framework version 1.1 execute improperly on version 1.0. Backward breaking changes are primarily made to implement security enhancements, while forward breaking changes are generally introduced to fix behavioral errors in version 1.0.

Binary Breaking Changes
A binary breaking change means the signature of a type or member is changed. The change can range from renaming a method parameter to renaming the method itself or changing the type of a return value. Binary changes are usually backward and forward incompatible. Although there are binary changes in the .NET Framework version 1.1, the effect of these changes is minimal. This is because the modifications apply only to types or members in version 1.0 that were reserved or technically unusable.

Behavioral Breaking Changes
A behavioral breaking change means the way a type or member operates is changed. A behavioral breaking change is often more subtle and harder to identify than a binary breaking change. Behavioral breaking changes can be backward, forward, or both backward and forward incompatible.   Behavioral breaking changes are seldom made to the .NET Framework except to correct coding errors or enhance reliability and security.

Redirecting Applications
By default, an application only works with the version of the .NET Framework with which it was compiled. In this case, no configuration file is necessary to execute the application. However, if you want an application built with one version of the .NET Framework to execute on one or more different versions of the .NET Framework, then you must use an appropriate configuration file.

Specifying the version of the .NET Framework the application is to use is called redirecting the application. An application can be redirected to use only a particular version of the .NET Framework, or one of a set of candidate versions selected by order of preference. You can create the configuration file automatically using Visual Studio .NET, or manually using the following information.   If your application does not have a configuration file, create one in the same directory as your application. Name the configuration file the same name as your application with ".config" appended to the name. For example, if the name of an application is MyApp.exe, then the name of the corresponding configuration file is MyApp.exe.config.

Configuration File Tags
Redirect your application by specifying the appropriate configuration file tags. In this example, the <requiredRuntime> tag is used to redirect your application to a computer that only has the .NET Framework version 1.0 installed.

<startup>
<requiredRuntime imageVersion="v1.0.3705" version="v1.0.3705" />
</startup>

For the .NET Framework version 1.0, the configuration file needs to redirect any dependent assemblies your application requires because version 1.0 does not automatically reference dependent assemblies. As a result, your configuration file can be very large. In this example, an assembly is redirected to the .NET Framework version 1.0.

<dependentAssembly>
<assemblyIdentity name="Accessibility" publicKeyToken="b03f5f7f11d50a3a" culture=""/>
<bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="1.0.3300.0"/>
</dependentAssembly>

For the .NET Framework version 1.1, the configuration file is smaller because the runtime automatically references dependent assemblies on your behalf. The ability of the .NET Framework to automatically reference dependent assemblies is called unification. That means you only need a simple configuration file to unify an application and its referenced assemblies with one version of the .NET Framework.

Specify one or more <supportedRuntime> tags in your configuration file to indicate the versions of the .NET Framework your application can execute on. The order of the tags indicates the preferred order of candidate .NET Framework versions. That is, the first tag indicates the foremost version you want to use; if that version is not installed, then the second tag indicates the second most preferred version you want to use, and so on.   The following example redirects an application built with the .NET Framework version 1.0 to execute on version 1.1.

<startup>
<supportedRuntime version="v1.0.5000" />
</startup>

If the .NET Framework version 1.1 is installed on your computer, specify multiple <supportedRuntime> tag entries to specify multiple versions of the .NET Framework. If you want an application to run on the .NET Framework version 1.0, you still need a <requiredRuntime> tag and the redirection tags for each assembly your application uses. In the following example, the .NET Framework version 1.1 is preferred, but if that version is not available, version 1.0 is used.

<startup>
<requiredRuntime imageVersion="v1.0.3705" version="v1.0.3705" />
<supportedRuntime version="v1.0.5000" />
<supportedRuntime version="v1.0.3705" />
</startup>

Configuration Files for Mixed Versions of Applications and Frameworks
The following describes the part of the configuration file required to run various versions of your application on various versions of the .NET Framework.
 
To run an application built with the .NET Framework version 1.0 on version 1.0, no redirection is necessary. This is the default behavior of a .NET Framework version 1.0 application.

To run an application built with the .NET Framework version 1.0 on version 1.1, include a configuration file with your application like the following:

<?xml version ="1.0"?>
<configuration>
<startup>
<supportedRuntime version="v1.0.5000" />
</startup>
</configuration>

To run an application built with the .NET Framework version 1.0 on either version 1.0 or version 1.1, include a configuration file with your application that includes two <supportedRuntime> tags, and a <requiredRuntime> tag. The first <supportedRuntime> tag redirects to .NET Framework version 1.0. The <requiredRuntime> tag redirects to version 1.0.

Include redirection sections for all assemblies referenced by your application. Redirect these assemblies to version 1.0 since these sections are not used by version 1.1.
For example:

<startup>
<requiredRuntime imageVersion="v1.0.3705" version="v1.0.3705" />
<supportedRuntime version="v1.0.3705" />
<supportedRuntime version="v1.0.5000" />
</startup>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Regcode"
publicKeyToken="b03f5f7f11d50a3a" culture=""/>
<bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535"
newVersion="1.0.3300.0"/>
</dependentAssembly>
<!-- Include a section for each assembly to be redirected. -->
</assemblyBinding>
</runtime>

To run an application built with the .NET Framework version 1.1 on version 1.1, no redirection is necessary. This is the default behavior for a .NET Framework version 1.1 application.

To run an application built with the .NET Framework version 1.1 on the .NET Framework version 1.0, include a <requiredRuntime> tag in your configuration file that points to the .NET Framework version 1.0. Include all necessary redirections for assemblies your application references.

To run an application built with the .NET Framework version 1.1 on version 1.1 or version 1.0, include a configuration file with your application that includes two <supportedRuntime> tags, and a <requiredRuntime> tag. The first <supportedRuntime> tag redirects to .NET Framework version 1.1. The <requiredRuntime> tag redirects to the .NET Framework version 1.0.

Include redirection sections for all assemblies referenced by your application. Redirect these assemblies to the .NET Framework version 1.0 since these sections are not used by .NET Framework version 1.1.

Testing Applications
Ideally you should test your application on all versions of the .NET Framework that you expect to support. You will need to recompile your application or change configuration settings to test it on different versions of the .NET Framework.

To run a .NET Framework version 1.0 application on version 1.1 (Backward Compatibility), Microsoft recommends that you perform your test on a separate computer that only has .NET Framework 1.1 installed, using the following steps:
 
1.      Compile your original application on the .NET Framework version 1.0.
2.      Create the necessary configuration file to target the .NET Framework version 1.1.
3.      Copy the compiled binary files to a computer with only the .NET Framework version 1.1 installed.
4.      Run the application.

To run a .NET Framework version 1.1 application on version 1.0 (Forward Compatibility), perform your test on a separate computer that only has the .NET Framework version 1.0 installed.
 
1.      Compile your original application on the .NET Framework version 1.1.
2.      Create the necessary configuration file to target the .NET Framework version 1.0.
3.      Copy the compiled binary files to a computer with only the .NET Framework version 1.0 installed.
4.      Run the application. If the application fails, it might be because you are using some functionality specific to the .NET Framework version 1.1. In that case, you must modify your application to only use .NET Framework version 1.0 functionality.

Windows Server 2003 Issues

The .NET Framework 1.1 and Visual Studio.NET 2003 will install on either Windows 2000 or Windows Server 2003. One of the main advantages developers will find with Windows Server 2003 is that IIS 6.0 provides a much more bulletproof, scalable web server platform than IIS 5.0. Windows Server 2003 is worthy of an entirely separate writeup, one which you will see here soon. The most important consideration when installing ASP.NET 1.1 on Windows Server 2003 is to make sure that it is "Enabled" in IIS Manager, as everything in IIS 6.0 on Windows Server 2003 comes "Prohibited" (locked down) by default as part of Microsoft's security posture.

All in all, Visual Studio.NET promises an even more exciting, stable and performant development environment to work under, both for developers and administrators. Combined with the power, security and stability of Windows Server 2003, we can look forward to a more productive, bug-free environment with which to deliver world - class applications, webservices and database applications.