.NET Framework Support on Windows Operating Systems

Summary: Provides information about which versions of Microsoft Windows that the Microsoft .NET Framework can be installed on. Software requirements of the .NET Framework and exceptions to the general platform support are listed. Explains how to prepare applications for cross-platform support. (14 printed pages)

Contents

Supported Platforms

The .NET Framework can be installed on the platforms shown in Table 1.

Table 1. Platforms the .NET Framework can be installed on

Supports all of the .NET Framework except Microsoft ASP.NET

Supports the entire .NET Framework

Windows 98

Windows 2000 (all versions—no Service Packs required)

Windows 98 SE

Windows XP Professional

Windows ME

Windows NT 4.0 (all versions - Service Pack 6a required)

Windows XP Home Edition

The first thing to notice is that the .NET Framework will not run at all on Windows 95. This is consistent with other Microsoft® products like Microsoft® Office XP that also do not support Windows 95.

The operating systems, on which the .NET Framework will run, can be divided in two groups: one that will run the .NET Framework with ASP .NET and one that will run it without. This can also be seen as the distinction between operating systems that can be used as a server for .NET applications and operating systems that should be used as clients running .NET applications. Note that all of the versions of Windows NT 4.0, even the Server edition, should be regarded as a client operating system for .NET applications.

Besides ASP .NET, there are only minor differences between the functionality supported by the .NET Framework on different platforms. For example, Windows 98 and Windows ME don't have an event-logging system, and the .NET Framework installed on these systems will therefore not support the Eventlog and related objects from the System.Diagnostics namespace.

Another area where some differences can be found is XML Enterprise Services. Windows NT 4.0 supported the installation Microsoft® Transaction Server (MTS), which is different from COM+ 1.0 which came with Windows 2000, or COM+ 1.5 which comes with Windows XP. XML Enterprise Services in the .NET Framework will only work with COM+ 1.0 or higher, so the functionality offered through the System.EnterpriseServices namespace won't be available at all on Windows NT 4.0 and will be partially available on Windows 2000.

.NET Framework Software Requirements

Internet Explorer 5.01

The .NET Framework and the underlying common language runtime contain a number of elements that rely on technology delivered by some version of Internet Explorer. The ability to download code, cryptography and intra/internet zone detection are examples of such elements. Technology requirements and the fact that Microsoft Internet Explorer 5.01 reached broad deployment led to the decision to set this version as the minimum version required to install and run the .NET Framework.

Table 2 shows that Internet Explorer 5.01 must be installed on Windows 98, Windows 98 SE and Windows NT 4 before the .NET Framework can be installed. Windows ME, Windows 2000 or Windows XP operating systems already contain Internet Explorer 5.01 or higher, so no further action needs to be taken.

MDAC 2.6

The Microsoft® Data Access Components (MDAC) have been Microsoft's way to distribute the technology that implements the Universal Data Access Paradigm. MDAC can be downloaded and installed separately or comes with the operating system or other software like Microsoft® SQL Server™, Office XP or any other application that included the components in its setup.

In order to work, the functionality from the System.Data namespace (which is Microsoft® ADO.NET) requires MDAC 2.6 or higher to be available. The complete version number for which the runtime checks is MDAC 2.6.6526.

When installing the Framework on one of the operating systems regarded as one of the valid server operating systems for the .NET applications (any Windows 2000 version or Windows XP Professional), the setup will actually issue a warning if MDAC 2.7 or higher is not available. This is a warning that you can ignore, but not a blocking issue that will abort the installation. Figure 1 shows such a warning.

Figure 1: Setup warning

Installing the .NET Framework on any of the other operating systems (Windows 98, Windows ME and Windows NT 4.0) does not issue a warning at all when MDAC is not available, although it's also a requirement on these systems for ADO.NET to work.

So this means that the setup of the .NET Framework on Windows 2000 or Windows XP Professional checks for a different version (2.7) than the version that is required a runtime (2.6.6526).

Other requirements

When installing the .NET Framework on Windows 2000, a warning will be issued when Internet Information Server 5 (IIS 5) is not installed and when doing the installation on Windows XP Professional, a warning is raised when IIS 5.1 is not available. On other operating systems, ASP.NET is not supported so the setup does not check for the presence of IIS.

When writing code that uses Windows Management Instrumentation (WMI) events and classes, .NET application will make use of the System.Management namespace. If WMI is not supported on the operating system, the functionality in this namespace will not work.

PlatformNotSupportedException

There are some software components that are required by some parts of the .NET Framework but that do not block the installation. If components are required at runtime but not available, the .NET Framework will throw an Exception of the type PlatformNotSupportedException that your own applications should be prepared for. More about that in the next section.

Preparing for Cross-Platform Support

Rich support across a broad array of platforms has been a design requirement since the inception of the .NET Framework. As a result, a significant amount of the value proposition offered by the .NET Framework comes from its ability to provide developers with a clear path for writing applications that work across a broad range of platforms. A .NET Framework class in general is limited only by the need for a common language runtime to exist on the underlying platform.

As always, there are exceptions to such a general statement and this article is really all about making those exceptions clear. So when designing a managed class, portability across the supported platforms should always be taken into consideration. The best way to ensure portability across the platforms supported by the .NET Framework is to build your classes using other managed code classes already available in the .NET Framework. Any time you create a .NET class that calls a native API, the risk of not supporting the breadth of officially supported platforms increases.

As the .NET Framework is a new technology, there will be cases where a new class has a legitimate need to call into Win32® or other native APIs, but this should be done with a solid understanding of trade-offs being made and how the platform support story is affected by that decision. With that thought in mind, some questions that are important to ask are:

•If the technology needs some data about the underlying system; can it be obtained using the System.Management layer rather than calling the native APIs?

•If Win32-native APIs really need to be called, can those APIs be called that are supported across the platforms instead of calling the "Ex" methods that might limit the ability to work on down-level platforms?

As the OS layer underneath the .NET Framework continues to evolve with new releases, there will be cases where a .NET class needs to rely on underlying OS technology that isn't available in all of the supported operating systems. In this case, the class designer will need to weigh the cost of supporting that class across all platforms compared to the utility that the target customers will derive from having that functionality available on each of the down-level operating systems. If possible, the class should either provide the equivalent functionality on down-level platforms, or provide a subset of the functionality on those platforms. In cases where the class just won't work without a certain piece of the underlying OS, say IIS for example, the class should not install on that platform or it should check for the underlying dependency and throw a PlatformNotSupportedException when that dependency is not available.

Suppose an application trying to create a managed Socket object calls the Socket constructor on an operating system that doesn't have Winsock installed. The following exception will be thrown.

"PlatformNotSupportedException: Socket cannot be created due to a missing required platform component, Winsock 1.1"

When working with managed classes from namespaces mentioned in the appendix, it's a good idea to add code to handle the PlatformNotSupportedException.

Consider the case of an application in which you want log specific events. If this application needs to run on Windows 2000 as well as on Windows 98, you will need to consider writing events to the event log for Windows 2000 as well as to a text file for Windows 98. You can check the appendix to see on which operating systems the EventLog object from the System.Diagnostics namespace is supported. The following code shows how you can write to an event log if this is supported, or fall back on writing to an ordinary text file if it's not.