The MS .NET Framework 1.1 Software Development Kit 1.1 Beta includes some new features and also changes in existing features.
The .NET Framework 1.1 SDK Beta runs on:
Microsoft Windows® .NET Server
Microsoft Windows 2000 (SP 2 recommended)
Microsoft Windows XP Professional

This new version of .NET Framework SDK can be download here. It's about 128 Mb.

Before installing the .NET Framework SDK 1.1 Beta, you must first install the .NET Framework Version 1.1 Beta 1. You can download the Framework from the .NET Framework download page.

Bear in mind that 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 .

also 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.

and also if an application written with the .NET Framework 1.1 Beta is installed on a system with only the .NET Framework 1.0 redistributable, it will not run (unless configure to do so).

The table below includs the new features and improvements of .NET SDK

Special thanks to www.gotdotnet.com team for the details about .NET SDK 1.1

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	.NET Framework version 1.1 has added a revalidation of Dataset after change of locale.
Area	System.Data
Affected APIs	Dataset.Locale()
Description	In .NET Framework version 1.0, it is possible to create a schema and document that are validated in only one locale. For example, load and validate the document, then change the locale. The document is not invalid, but the dataset has not revalidated the document. Other APIs, such as ChangeCaseSensitivity(), will cause a revalidation of the document, , so this behavior is expected when changing locale. If your .NET Framework version 1.0 application relies on setting the locale of the dataset after a document is validated, then the application might fail in .NET Framework version 1.1.
Workaround	No workaround is available for this change. Generally, this indicates that the change is not intended to have a workaround
Title	End tag in XML is now consumed by DataSet.ReadXml(). It was not consumed earlier.
Area	System.Data
Affected APIs	System.Data.DataSet.ReadXml()
Description	In .NET Framework version1.0, the end tag was not consumed. Therefore an attempt to read the following XML fragment resulted in only the first element being read and loss of all other data. <e1> <x/> </e1> <e1> <x/> </e> In .NET Framework version 1.0, an application improperly reads an XML fragment into a DataSet and ignores the data loss. In .NET Framework version 1.1, we consume the end-tag, which causes the application to throw an exception. Populating a DataSet with XML fragments (XmlReadMode Fragment) using a properly constructed XmlTextReader is the.NET Framework version 1.0 feature affected by this change.
Workaround	Eliminate redundant (previous workaround) calls to XmlReader.Skip to skip the end tag. Verify that fragments are read in with XmlReadMode.Fragment.
Title	New exception in OleDbConnection.Execute() when binding with (BYREF)|unexpected.
Area	System.Data
Affected APIs	OleDbConnection.Execute()
Description	It is possible for an OLE DB provider to provide metadata that indicates that the type to be bound is (BYREF)|(unexpected). OLE DB clientcannot bind this type of parameter. In .NET Framework version 1.0, nothing happens; OLE DB client silently fails in this scenario. In .NET Framework version 1.0 Debug you get an assert in this situation. In .NET Framework version 1.1, you get an exception.
Workaround	To emulate .NET Framework version 1.0 behavior, catch and ignore the new GVtUknown exception.
Title	.NET Framework version 1.0 did not allow the use of dataset aggregate expressions involving relationships.
Area	System.Data
Affected APIs	DataSet.ReadXML(), DataSet.BeginInit(), DataSet.EndInit()
Description	There was no way in .NET Framework version 1.0 for a dataset to create columns using aggregate functions from other tables. When you called BeginInit() or EndInit(), and when serializing/deserializing these datasets you would get an "Exception has been thrown by the target of an invocation."
Workaround	No workaround is available for this change. Generally, this indicates that the change is not intended to have a workaround
Title	Require FullTrust for OLEDB, ODBC and OracleClient.
Area	System.Data
Affected APIs	Various
Description	Parts of System.Data can now be used in partially trusted applications, such as SQL Client. This means that it is now necessary to require FullTrust permission for OLE DB, ODBC and OracleClient. It is not possible to allow these providers to work in partially trusted scenarios due to their interaction with native pointers and APIs.
Workaround	If you are using .NET Framework version 1.0 and are setting system.data.dll as allowed in partially trusted scenarios, you must modify your security settings to allow these components to work in partially trusted scenarios.
Title	Calling SQLClientPermission.PermitOnly() and calling SQLConnection.Open() results in an unexpected SecurityException().
Area	System.Data
Affected APIs	SQLConnection.Open()
Description	In .NET Framework version 1.0, SQLClient unnecessarily checked for UnmanagedCodeAccess during Open. The only time unmanaged code access is required is in SQL stored procedure debugging scenarios. Imitating this practice could lead people to unnecessarily enable UnmanagedCodeAccess for SQLClient.
Workaround	No workaround is available for this change. Generally, this indicates that the change is not intended to have a workaround
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	Removed an OnStateChange( Open ) event from OLE DB client and ODBC client packages.
Area	System.Data
Affected APIs	OLEDBConnection.OnState
Description	The .NET Framework version 1.0 was incorrectly firing an OnStatechange(Open) event when there was an invalid connection string.
Workaround	No workaround is available for this change. Generally, this indicates that the change is not intended to have a workaround
Title	Complex types can end up in an incorrect namespace.
Area	System.Data
Affected APIs	DataSet.ReadXML(), DataSet.WriteXML()
Description	Can occur when one XSD includes a second XSD. The second XSD file contains both element types and complex types. The first XSD file contains a namespace declaration. The second XSD does not contain a namespace declaration. The element types will be placed in the first XSD's namespace. The complex types end up without a namespace. When you read and write the dataset to and from XML you will get an unexpected exception. This can cause problems when working with tools that generate valid XSDs, when those XSDs are read to and from the dataset.
Workaround	No workaround is available for this change. Generally, this indicates that the change is not intended to have a workaround
Title	Security issue. The default behavior for OLE DB package was to allow blank passwords.
Area	System.Data
Affected APIs	OleDbConnection.Open()
Description	In .NET Framework version 1.1, OLE DB package will by default not allow connection strings with blank passwords. If your application relies upon blank passwords it will fail to connect to the database using the .NET Framework version 1.1 version of OLE DB package.
Workaround	Supply passwords for connection strings. Edit your security configuration to allow blank passwords.
Title	DataSet does not reload properly when expressions are based on other columns.
Area	System.Data
Affected APIs	DataSet.BeginInit(), DataSet.EndInit().
Description	This is a special case of bug 74737. To replicate, use Visual Studio DataSet Designer to create three columns, and set the second column to an expression already applied to the third column. Then cause the designer to refresh and switch from one window to another. The result is that the second and third columns disappear, an error message displays indicating that column 1 is already in a DataTable and column 3 cannot be found.
Workaround	No workaround is available for this change. Generally, this indicates that the change is not intended to have a workaround
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	New exception in SQLClient when parameter binding precision is less than the value precision. Now correctly truncates on the client when the parameter scale is less than the binding scale.
Area	System.Data
Affected APIs	SQLConnection.Execute(), SQLConnection.ExecuteNonQuery() with bound parameters.
Description	In the case of a value such as 1234.567 and a parameter binding such as decimal(5,2), the precision of the value is greater than the precision of the binding. In this case, invalid data is occasionally inserted into the database. This new exception will not be expected for applications written against the .NET Framework version 1.0 of these components.
Workaround	No workaround is available for this change. Generally, this indicates that the change is not intended to have a workaround
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	ExecuteReader() with CommandBehavior.SingleRow no longer throws an exception when no rows are returned.
Area	System.Data
Affected APIs	OleDbCommand.ExecuteReader()
Description	In .NET Framework version 1.0, OleDbCommand, ExecuteReader() with a CommandBehavior.SingleRow could throw an invalid OleDbException: "Object or data matching the name, range, or selection criteria was not found within the scope of this operation." In .NET Framework version 1.1 this result now returns an empty DataReader object. Applications that are coded to handle the exception will need to be modified to instead work with the empty reader.
Workaround	User could code a wrapper around OleDbCommand.ExecuteReader() to catch the exception and create the empty reader.
Title	Formatting and parsing of DateTimes now use and recognize genitive month names.
Area	System.DateTime
Affected APIs	DateTime.ToString (all) DateTime.Parse (all) DateTime.ParseExact (all) Convert.ToDateTime(string) Convert.ToString(DateTime)
Description	Certain cultures, such as Russian, Czech, Polish, and Serbian use genitive forms for the month names in certain contexts. For example, in Russian, the non-genitive form of the English 'August' is 'Avgust'. However, when used in patterns such as the LongDatePattern, the form returned should be 'Avgusta.' In .NET Framework version 1.1, cultures return the correct genitive forms of month names when the context requires it.
Workaround	No workaround is available for this change. Generally, this indicates that the change is not intended to have a workaround
Locales	Examples include Russian, Czech, Polish, and Serbian.
Title	Short dates after 2010 now roundtrip in the TaiwanCalendar.
Area	System.DateTime
Affected APIs	System.DateTime.ToString System.DateTime.Parse
Description	In .NET Framework version 1.0, short dates do not round trip after 2010 for the TaiwanCalendar. The reason is that formatting a short date after 2010 would print the year using only two digits, but this is not enough information: it should print three digits (2010 is the year 100 in the TaiwanCalendar). The new behavior is that when we format the Taiwan Calendar using "yy", we now print three digits to enable the roundtripping and avoid confusion.
Workaround	No workaround is available for this change. Generally, this indicates that the change is not intended to have a workaround
Locales	TaiwanCalendar
Title	In the Hebrew Calendar, the month of Adar is now named correctly in a leap year.
Area	System.DateTime
Affected APIs	System.DateTime.ToString System.DateTime.Parse System.DateTime.ParseExact
Description	In leap years in the Hebrew Calendar, there is an extra month, which is labeled 'Adar II'. During this year, the month normally labeled 'Adar' should be changed to 'Adar I'. This was not happening in .NET Framework version 1.0, but has been rectified in .NET Framework version 1.1.
Workaround	Format the month name with the extra 'I' manually.
Locales	HebrewCalendar only
Title	GetAbbreviatedEraName now returns the correct value for Chinese in Hong Kong.
Area	System.Globalization
Affected APIs	System.Globalization.DateTimeFormatInfo.GetAbbreviatedEraName(int).
Description	In .NET Framework version 1.0, the string returned by DateTimeFOrmatInfo.GetAbbreviatedEraName method is "Î÷Ôª". This is incorrect however, since the calendar used by zh-HK is in English. The correct result is "AD". This has been fixed in .NET Framework version 1.1.
Workaround	None. The old behavior is invalid.
Locales	zh-HK (Chinese - Hong Kong SAR)
Title	The NativeName for neutral Urdu is now correct.
Area	System.Globalization
Affected APIs	System.Globalization.CultureInfo.NativeName
Description	In .NET Framework version 1.0, the NativeName for Urdu (neutral) was \x0671\x0631\x062f\x0648. However, the correct NativeName is actually \x0627\x064f\x0631\x062f\x0648. This has been fixed in .NET Framework version 1.1.
Workaround	No workaround is available for this change. Generally, this indicates that the change is not intended to have a workaround
Locales	ur (Urdu)
Title	The NativeName for Tatar in Russia, has been fixed.
Area	System.Globalization
Affected APIs	System.Globalization.CultureInfo.NativeName
Description	The NativeName for Tatar in Russia should comprise the following: u0422\u0430\u0442\u0430\u0440 (\u0420\u043e\u0441\u0441\u0438\u044f). However, in .NET Framework version 1.0, it only comprised the first part: \u0422\u0430\u0442\u0430\u0440. This has been fixed in .NET Framework version 1.1.
Workaround	No workaround is available for this change. Generally, this indicates that the change is not intended to have a workaround
Locales	tt-RU (Tatar - Russia)
Title	CultureInfo on thread will be read-only by default.
Area	System.Globalization
Affected APIs	none
Description	The CultureInfo object on the thread will be a read-only object. This doesn't affect the culture ID setting on the page -- the user will still get the proper one on the request. Also, if the user has enough permission he/she can change the CultureInfo object of the thread with a custom one, but that will be in effect only for the remainder of that request.
Workaround	No workaround is available for this change. Generally, this indicates that the change is not intended to have a workaround
Title	CultureInfo.ClearCachedData now clears Timezone data correctly.
Area	System.Globalization
Affected APIs	System.Globalization.CultureInfo.ClearCachedData()
Description	In .NET Framework version 1.0, a call to ClearCachedData would not clear cached Timezone data correctly. This has been rectified in .NET Framework version 1.1.
Workaround	No workaround is available for this change. Generally, this indicates that the change is not intended to have a workaround
Title	The long date pattern and negative currency pattern are now updated for Canadian French.
Area	System.Globalization
Affected APIs	System.Globalization.DateTimeFormatInfo.LongDatePattern
Description	In Canadian French (fr-CA), the long date pattern and the negative currency pattern have been changed. They are now "d MMMM yyyy" and (<value> $) respectively (the difference in the second item is that a space has been added between <value> and the currency symbol. The new pattern is pattern 15).
Workaround	Set these patterns manually.
Locales	fr-CA (Canadian French)
Title	CultureInfo.TwoLetterISOLanguageName is now correct for neutral cultures.
Area	System.Globalization
Affected APIs	System.Globalization.CultureInfo.TwoLetterISOLanguageName
Description	CultureInfo.TwoLetterISOLanguageName should match each neutral culture's CultureInfo.Name. In addition, the two-letter language name is expected to be the same for a culture and all its subcultures. In .NET Framework version 1.0, this was not true for two cultures: ky" (0x0040), TwoLetterISOLanguageName: kz. The correct value should be "ky" "kok" (0x0057), TwoLetterISOLanguageName: hi. The correct value should be "kok" These have been fixed in .NET Framework version 1.1.
Workaround	Reference the non-neutral culture TwoLetterISOLanguageNames instead
Locales	ky (Kyrgyz)
Title	RegionInfo.DisplayName for the Faroe islands is now corrected.
Area	System.Globalization
Affected APIs	System.Globalization.RegionInfo.DisplayName.ToString()
Description	The RegionInfo DisplayName for the Faroe Islands was incorrectly spelled as "Faeroe Islands" in .NET Framework version 1.0. This has been rectified in .NET Framework version 1.1.
Workaround	No workaround is available for this change. Generally, this indicates that the change is not intended to have a workaround
Locales	FO (Faroe Islands)
Title	ICertificatePolicy is not called for Expired Certificate Revccation List (CRL) error codes.
Area	System.Net
Affected APIs	System.Net.ICertificatePolicy
Description	ICertificatePolicy is not called for Expired CRL error codes. Issuers of certificates maintain a list of certificates that have been revoked. A certificate on this list should not be trusted. In .NET Framework version 1.0, we do not check certificates against the Certificate Revocation List. This fix enables that check.
Workaround	Set the config switch that we're adding to not do the check, thus reverting to the .NET Framework version 1.0 behavior. Additionally, you have the option to overwrite additional code to override (ignore) the error generated by the check.
Title	In .NET Framework version 1.0, if the developer passed in a custom certificate error handler it was only called if an error was identified by the CAPI. We need to call the handler even if CAPI finds no errors.
Area	System.Net
Affected APIs	Any class that implements the ICertificatePolicy.
Description	In .NET Framework version 1.0, if the developer passed in a custom certificate error handler it was only called if an error was identified by the CAPI. We need to call the handler even if CAPI finds no errors.
Workaround	No workaround is available for this change. Generally, this indicates that the change is not intended to have a workaround
Title	Added permission demands to two methods.
Area	System.Net
Affected APIs	1) Add permission demand on GetDefaultProxy() 2) Use ProxyRegBlod.GetIEProxy in places where we read the configuration.
Description	In NCL, we disallow a partially trusted application from discovering the proxy. We do this by adding demands on: HttpWebRequest::get_Proxy GlobalProxySelection::get_Select However, there are three other places from where a partially trusted application can discover the proxy: HttpWebRequest::get_ServicePoint WebProxy::GetDefaultProxy() HttpWebResponse::Headers["Via"]
Workaround	No workaround is available for this change. Generally, this indicates that the change is not intended to have a workaround
Title	There is now a way to limit the size of reply headers in HttpWebRequest.
Area	System.Net
Affected APIs	System.Net.HttpWebRequest
Description	HttpWebRequest parses the HTTP headers in the reply. If the server sends an enormous header, the client exhausts memory trying to read the headers. The change is to limit the size of the headers.
Workaround	By default the size is now 64k. You are allowed to change the default size programmatically and through the configuration file.
Title	Uri class could not parse escape "#" in http://a/b/c/d?p#q .
Area	System.Net
Affected APIs	System.Uri
Description	Previously, the Uri class parsed: http://a/b/c/d?p#q as http://a/b/c/d?p%23q. Per the RFC for this feature, we should parse this as "?p" for the query part, and "#q" for the fragment part. This has been fixed.
Workaround	No workaround is available for this change. Generally, this indicates that the change is not intended to have a workaround
Title	ConnectStream.Read() and ConnectStream.Write() now honor Timeouts.
Area	System.Net
Affected APIs	System.Net.HttpWebRequest
Description	HttpWebRequest.Timeout allows you to set a timeout for users performing synchronous GetResponse and GetRequestStream operations. Calling HttpWebRequest.GetResponse().GetResponseStream() or HttpWebRequest.GetRequestStream returns a stream you can use to read or write HTTP data. However, a synchronous Read() or Write() to the stream always blocked without honoring this timeout. The timeout is now honored for these methods.
Workaround	No workaround is available for this change. Generally, this indicates that the change is not intended to have a workaround
Title	Added IPv6 support for .NET Framework version 1.1.
Area	System.Net
Affected APIs	The main API affected is the Dns.Resolve method.
Description	Added support for IPv6.
Workaround	Configuration switch that allows IPv6 support to be turned on or off.
Title	BeginConnect and BeginAccept caused a callback on failure. This is incorrect If a BeginXxx() call throws an exception, there should be no callback.
Area	System.Net
Affected APIs	BeginConnect/BeginAccept
Description	BeginConnect and BeginAccept cause a callback on synchronous failure. This is incorrect. If a BeginXxx() call throws an exception, there should be no callback.
Workaround	No workaround is available for this change. Generally, this indicates that the change is not intended to have a workaround
Title	Added Inheritance Demand on ResolveURI() method on the XmlResolver class.
Area	System.Net
Affected APIs	ResolveURI() method on the XmlResolver class.
Description	Applications that inherit from XmlResolver and run in semi-trusted code will be broken. This is a security issue. This is required since by overriding this method a malicious attacker can alter the returned absolute URI to point to an untrusted site or attack otherwise denied sites. Applications that need to inherit from XmlResolver should be fully trusted.
Workaround	None. This is a security hole.
Title	SSL Server Certificate : ICertificatePolicy is not called for Certificate No Match error codes.
Area	System.Net
Affected APIs	System.Net.ICertificatePolicy
Description	In this situation, the host name associated with the server certificate doesn't match the host name associated with the site. For example, a server certificate issued to www.example.com is being served from a site called www.another_example.com.
Workaround	If this breaks an existing application, the user can set the configuration flag to not do the check. This will provide the same behavior that the user is accustomed to with .NET Framework version 1.0. The user also has the option to write additional code to override the error identified by doing the check.
Title	Error in Site membership condition fixed - cannot create site values for the SiteMembershipCondition from file URLs anymore.
Area	System.Security
Affected APIs	System.Security.Policy.Site.CreateFromUrl
Description	Our documentation and security model for site identity says that "Site identity is defined for code from URLs with any protocol except FILE". Thus, it is not applicable to local intranet locations. However, in .NET Framework version 1.0 it was possible to create Sites from some File URLs. This has been fixed and the SiteCreateFromUrl method will not succeed for any File Url input values, but throw an exception instead.
Workaround	None, this was a semantic bug in the System.Security.Policy.Site class
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	Invalid range check fixed on StringBuilder constructor.
Area	System.Text
Affected APIs	System.Text.StringBuilder(string, int, int, int)
Description	In .NET Framework version 1.0, passing null (Nothing) as the first value to the Stringbuilder(string,int,int,int) constructor didn't throw any exception, but would result in an empty string being added to the StringBuilder, even if the specified range was invalid. In contrast, if String.Empty was passed as that value, then an ArgumentOutOfRange exception was thrown if the specified range was invalid. We now check the startIndex and count parameters passed to this constructor, and if the string passed is null, then an ArgumentException is thrown if these values are null. This is consistent with how String.Empty behaves.
Workaround	No workaround is available for this change. Generally, this indicates that the change is not intended to have a workaround
Title	The BodyName for CodePage 1257 has changed.
Area	System.Text
Affected APIs	System.Text.Encoding.BodyName
Description	In Windows, the BodyName for CodePage 1257 has been renamed "Windows-1257." It was "ISO-8859-4". Code that might have hit this includes anything that used the GetEncoding method to retrieve code page 1257, and then display, or use the BodyName. For example: Encoding e = Encoding.GetEncoding(1257); String s = e.BodyName; //display or use the s string in some way.
Workaround	No workaround is available for this change. Generally, this indicates that the change is not intended to have a workaround
Title	ComboBox now raises MouseDown event twice for middle and right mouse button double click
Area	System.Windows.Forms
Affected APIs	System.Windows.Forms.ComboBox
Description	In version 1.0, the ComboBox control raised only a single MouseDown event when the ComboBox was double clicked with either the middle or right mouse button. This has been fixed so that two MouseDown events are now raised.
Workaround	No workaround is available for this change. Generally, this indicates that the change is not intended to have a workaround
Title