What's New in the .NET Framework 1.

1
The .NET Framework version 1.1 extends the .NET Framework version 1.0 with new features,
improvements to existing features, and enhancements to the documentation.

Native Support for Developing Mobile Web Applications

The .NET Framework 1.1 now features native support for developing mobile Web applications.
ASP.NET mobile controls (formerly the Microsoft Mobile Internet Toolkit) extend ASP.NET server
controls so that they adapt to the mobile device on which the Web application is rendering.
Through browser detection, the mobile controls conform to the capabilities of individual devices
ranging from full-featured personal digital assistant (PDA) browsers to small, 5-line × 20-
character mobile phone displays. This adaptive rendering feature handles many of the tedious,
device-specific rendering decisions and frees you to focus on your Web application logic. The .NET
Framework 1.1 incorporates the mobile controls into the .NET Framework and Microsoft Visual
Studio® .NET distributions.

Granular Version Control: Side-by-Side Execution

Support for side-by-side execution in the .NET Framework 1.1 enables systems administrators to
store and execute multiple versions of an application or component on the same computer. This
means that you can have multiple versions of the .NET Framework Redistributable, as well as
multiple versions of applications and components that use a version of the Redistributable, on the
same computer at the same time.
Side-by-side execution does not imply that a managed application is compatible with other
versions of the Redistributable or of a component. Rather, it means that a managed application
can choose the Redistributable and the components it executes with, and that multiple versions of
the Redistributable, applications, and components can coexist on the same computer. Systems
administrators control this through the application's configuration file. By default, in the absence
of configuration file instructions:
• If an application written with the .NET Framework 1.0 is installed on a system with only
the .NET Framework 1.1 Redistributable present, the application will try to run against
version 1.1.
• If an application written with the .NET Framework 1.0 is installed on a system with both
versions 1.1 and 1.0 of the Redistributable present, the application will run against version
1.0 unless an administrator changes the behavior.
• If an application written with the .NET Framework 1.1 is installed on a system with only
the .NET Framework 1.0 Redistributable, it will not run (unless configured to do so).

ASP.NET applications represent an exception to this behavior. When the .NET Framework 1.1
Redistributable is installed on a server, ASP.NET Web applications and XML Web services are, by
default, automatically configured to run with it. Again, systems administrators have the ability to
override this default behavior and configure some or all of these applications to run with the .NET
Framework 1.0 Redistributable.
For more information, see Versioning, Compatibility, and Side-by-Side Execution in the .NET
Framework.

Enable Execution of Windows Forms Assemblies Originating from the Internet

Assemblies originating from the Internet zone—for example, Microsoft Windows® Forms controls
embedded in an Internet-based Web page or Windows Forms assemblies hosted on an Internet
Web server and loaded either through the Web browser or programmatically using the
System.Reflection.Assembly.LoadFrom() method—now receive sufficient permission to
execute in a semi-trusted manner. Default security policy has been changed so that assemblies
assigned by the common language runtime (CLR) to the Internet zone code group now receive
the constrained permissions associated with the Internet permission set. In the .NET Framework
1.0 Service Pack 1 and Service Pack 2, such applications received the permissions associated with
the Nothing permission set and could not execute.
Note: While we are re-enabling code from the Internet zone, the defaults do not give this code
full access to the user's machine. By default, thanks to code access security, this code runs in a
restricted manner and is allowed access only to a limited set of resources that are safe to use.
This code cannot damage your data or system, and it cannot steal private information that you do
not explicitly give it.

Enable Code Access Security for ASP.NET Applications

Systems administrators can now use code access security to further lock down the permissions
granted to ASP.NET Web applications and Web services. Although the operating system account
under which an application runs imposes security restrictions on the application, the code access
security system of the CLR can enforce additional restrictions on selected application resources
based on policies specified by systems administrators. You can use this feature in a shared server
environment (such as an Internet service provider (ISP) hosting multiple Web applications on one
server) to isolate separate applications from one another, as well as with stand-alone servers
where you want applications to run with the minimum necessary privileges.

Native Support for Communicating with ODBC and Oracle Databases

Developers can now enjoy native support for communication with ODBC and Oracle databases.
The .NET Framework Data Provider for ODBC, which previously was available only as a Web
download, now ships with the .NET Framework under the namespace System.Data.Odbc. It
provides access to native ODBC drivers the same way the OLE DB .NET Data Provider provides
access to native OLE DB providers.
The .NET Framework Data Provider for Oracle, also previously available only as a Web download,
now ships with the .NET Framework under the namespace System.Data.OracleClient. It provides
access to Oracle databases using the Oracle Call Interface (OCI) as provided by Oracle Client
software.

Unified Programming Model for Smart Client Application Development

The Microsoft .NET Compact Framework brings the CLR, Windows Forms controls, and other .NET
Framework features to small devices. The .NET Compact Framework supports a large subset of
the .NET Framework class library optimized for small devices.
Supported devices include the Pocket PC 2000, Pocket PC 2002, Pocket PC 2002 Phone Edition,
and custom-designed embedded devices built with the Windows CE .NET 4.1 operating system.
Earlier versions of Windows CE .NET are not supported.
The .NET Compact Framework provides the following key features:
• A compact CLR that brings the benefits of managed code (such as memory management,
code reliability, and language neutrality) to devices.
• Consistency with desktop and server programming models.
• Seamless connection with Web services.
• Rich enterprise-class data access features with XML classes and ADO.NET.
• Classes to program applications that access data using Microsoft SQL Server™ 2000 and
Windows CE 2.0.
• Full access to native platform features through platform invoke.
• Just-in-time (JIT) compilation for optimal performance.
Note: The .NET Compact Framework does not ship natively with the .NET Framework. Developers
may access the .NET Compact Framework using Visual Studio .NET 2003.

Support for IPv6

The .NET Framework 1.1 supports the emerging update to the Internet Protocol, commonly
referred to as IP version 6, or simply IPv6. This protocol is designed to significantly increase the
address space used to identify communication endpoints in the Internet to accommodate its
ongoing growth.

Scalability, Performance, Documentation

In addition to the areas discussed above, significant improvements have been made to the .NET
Framework in the areas of scalability and performance. Enhancements have also been made to
the documentation, which now includes more code examples and several new sections (including
one entitled Secure Code Guidelines).
Title SQLClient .NET Framework version 1.0 always executes statements to SQL Server
using sp_executesql. If there is a batch of statements this method of execution
fails. This has been fixed.
Area System.Data
Affected SQLClient.Execute()
APIs
DescriptionIf you build your application dependant upon this functionality you will have to run
your application on .NET Framework version 1.1 or above. This fix was primarily to
allow SQL Server users to issue batch queries that look like:
Set statistics profile on
Select * from pubs. authors
Set statistics profile off
Workaround No workaround is available for this change. Generally, this indicates that the change
is not intended to have a workaround

Title In version 1.1 of the .NET Framework, we have added the ability to run SQLClient
in a partially trusted application environment
Area System.Data
Affected SQLClient
APIs
Description If you build your application dependant upon using SQLClient in a partially trusted
environment your application will only run on Version 1.1 or higher versions of the
framework.

Title Autogenerated ASP.NET forms authentication and viewstate keys are now isolated
per application by default.
Area Asp.NET
Affected APIs The ASP.NET Forms authentication feature as a whole when using autogenerated
keys. This includes:
FormsAuthentication.RedirectFromLoginPage // all
FormsAuthentication.SetAuthCookie // all
FormsAuthentication.GetAuthCookie // all
FormsAuthentication.Encrypt // all
FormsAuthentication.Decrypt // all
Description When using forms authentication across applications with the default
<machineKey> section in machine.config, applications are now isolated and will
not share forms authentication or viewstate keys.
This is due to the presence of a new modifier on the validationKey and
decryptionKey attributes called "IsolateApps". When this key is present, the
application identity is used a part of the key modifier so that keys are not shared
across applications. This was done to make it easier to configure isolated
applications on shared servers.
Note that if applications contain an explicit value for these attributes in the
web.config (this is required for Web farm deployments), then this is not an issue
and the configured value will be used. Similarly, if an application has an explicit
<machineKey> section in a local web.config file set to autogenerate, then that
application will not use the new modifier.
Note also that applications that have explicit values configured for the
<machineKey> section in web.config will not see a change in behavior on these
APIs. This applies only to applications that inherit the default machine.config
<machineKey> section for these values.
Workaround Configure an explicit key in a local web.config or in machine.config or remove the
"IsolateApps" modifier from the attribute. With the modifier removed, the .NET
 Framework version 1.0 behavior will be identical. Note that only applications that
want to share forms authentication cookies across applications are affected by this
change.
Title ASP.Net Web Services no longer rejects requests that come without the
wsdl:required headers.
Area Asp.NET
Affected APIs None
Description ASP.Net Web Services provides the ability to define SOAP envelope headers. When
specified as required within a web service, the generated WSDL will contain a
wsdl:required attribute on the soap:header element for a given operation.
Previously, ASP.Net Web Services would ensure that all SOAP requests for this
operation contained the specified required header by throwing a
SoapHeaderException if the header was omitted. As of this release, ASP.Net Web
Services no longer ensures that the required header is present. Application
depending on the above behavior may experience NullReferenceExceptions when
accessing headers marked as required.
Workaround Recompilation required. The application should test for the existence of the
required header rather than depending on ASP.Net Web Services to reject the
request.
Title Security related issue. In .NET Framework version 1.0,
SQLPermission.AllowBlankPassword is only checked if the user actually includes the
password keyword in their connection string.
Area System.Data
Affected APIs SQLConnection.Open()
Description It was possible for an administrator or user to set
SQLPermision.AllowBlankPassword= false, perhaps through the security.config file.
Even with this setting it is possible for a
usertospecifyaconnectionstringlike"server=(localhost);uid=sam". From a user
perspective, this would be expected to fail. In .NET Framework version 1.1 this
configuration will now fail.
Workaround Do not set up permissions to disallow blank passwords and allow the application to
issue connection strings without passwords.
Title Expect SQLReader.ExecuteReader() to throw an exception when selected as a
deadlock candidate.
Area System.Data
Affected APIs SQLDataReader.ExecuteReader()
Description In .NET Framework version 1.0 the user will not see the exception until
SQLDataReader.NextResult() is called. If the application has been coded to handle
deadlock exceptions at NextResult(), and is not expecting the ExecuteReader() to
throw the deadlocked exception, then the application will not work as expected in
.NET Framework version 1.1.
Workaround User can write code to catch exception at both ExecuteReader and NextResult().
Title In .NET Framework version 1.0, OleDbDataReader.Close() incorrectly throws an
exception if one statement in a batch of statements has an error.
Area System.Data
Affected APIs OleDbDataReader.Close()
Description You can issue multiple statements in a batch to SQL Server, however one or more
statements might fail. If you then call OleDbDataReader.Close(), you unexpectedly
get an exception. In .NET Framework version 1.1 this exception no longer occurs.
Workaround Write code that does not test for the exception from OleDbDataReader.Close(). In
order to run in both version 1.1 and version 1.0, write your code to ignore the
exception from OleDbDataReader.Close().
Title New exception thrown from SQLClient.Execute() when a transaction is deadlocked.
Area System.Data
Affected APIs SQLClient.Execute(), SQLClient.ExecuteScaler(), Execute.NonQuery()
Description Within complex transaction scenarios an application can cause a SQL Server
database server to deadlock a transaction. (See SQL Server Books Online for an
explanation of deadlocked transactions). When a transaction deadlock occurs, the
SQL Server will choose one of the connections involved in the deadlock and declare
that connection's work invalid. This frees up the deadlock so that other
transactions can be completed. When this happens the user will get a valid return
code from the affected APIs. If the user does a Read on the reader at this point the
user will get the expected exception.
Workaround User can write code to always read a SQLReader after ExecuteScaler() or Execute
NonQuery().
Title In .NET Framework version 1.0, Dataset treats a default value of "" (empty string)
as a DBNull. In .NET Framework version 1.1, Dataset now sets columns with a ""
default value to "".
Area System.Data
Affected APIs DataColumn.DefaultValue()
Description In .NET Framework version 1.0, this occurs if you do a WriteXml() followed by
aReadXml()(a "roundtrip") of a dataset that has a schema that defaults a column
to "". When you look at the dataset after the ReadXml ("roundtripped") you will
see that the new dataset default value is now DBNull. In .NET Framework version
1.1, when you execute a roundtrip, you will see that the default value stays as "".
If you have application scenarios that depend on "" defaults showing up as DBNull,
you will need to code them to handle the "" case as well.
Workaround User can write code that maps DBNull correctly to "" to handle the problem of .NET
Framework version 1.0 doing this incorrectly.
Title In .NET Framework version 1.1, code from the Internet is allowed to run again by
default within the safe Internet permission set constraints.
Area System.Security
Affected APIs Not applicable - this is a default security policy configuration change.
Description In .NET Framework version 1.1, default security policy has been changed to re-
enable code coming from the Internet to run within the safe Internet permission
set constraints. As an additional safeguard, by default all code that is not
Authenticode-signed will trigger a user prompt asking whether that particular code
should run. The user will have the chance to disable the prompt on a per zone
basis. This change applies only to applications that relied on security policy never
giving code that came from the Internet rights by defaultto run on the client
machine.
Workaround If a user or administrator wishes to revert to a policy state in which code from the
Internet is not run, the following steps will accomplish this:
1. Start the .Net Framework Configuration tool (shortcut found in the
administrative tools folder)
2. Right click on the Runtime Security Policy Node
3. Select the 'Adjust Security Wizard'
4. Select 'Make Changes to this computer' option [default option], click Next
5. Select the Internet icon
6. Pull down the slider to 'No Trust' (you may first need to reset internet zone
policy to it default state by clicking on default level)
7. Select Next and Finish the wizard
Title WSDL.exe now maps xsd:anyType schema elements to System.Object.
Area System.Xml
Affected APIs XmlSchemaImporter (not documented).
Description WSDL.exe previously mapped all schema elements with an xsd:anyType to
System.String. This mapping was changed to System.Object in this release.
Title Added a safety catch to the NGEN /DELETE command.
Area Tools
Affected APIs None -- command-line tool only.
Description Before this fix, typing NGEN /DELETE would silently delete all entries in the Native
Image Cache.
After this fix, typing NGEN /DELETE will issue the error message:
Error: Must specify at least one assembly to delete.

If the user actually wants to delete everything in the Native Image Cache, they
must use the command:
NGEN /DELETE *
Title Resgen.exe now gives detailed error information.
Area Tools
Affected APIs Resgen.exe
Description In .NET Framework version 1.0, Resgen.exe would capture detailed exception
information about the cause of a problem but simply display 'invalid resx file',
which might not have been the actual cause. This has been fixed in .NET
Framework version 1.1, so the real cause is now displayed by Resgen.exe.
Title Decimal class now preserves trailing zeroes after the decimal point.
Area Other
Affected APIs System.Decimal
Description In .NET Framework version 1.1, converting a Decimal to a string would never
display trailing zeroes after the decimal point, and operations on Decimals which
resulted in trailing zeroes would truncate those zeroes. In .NET Framework version
1.1, trailing zeroes are preserved under certain operations. For example, assigning
0.00500 to a Decimal will now result in "0.00500" being printed when converting
to a string. Or adding 0.05 to 0.05, will result in "0.010" if converted to a string.
Note that comparison behavior of decimals remains unaffected by this change.
Please see the documentation for details about the new behavior.
Workaround Use formatting values to format Decimals explicitly with the values of the old
behavior.