Basic Search  Advanced Search   
Topics Resources Free Library Software XML News About Us
home » info bank » articles » XML & Web Services Changes in .NET Framework 1.1 Sat, Feb 23, 2008

XML & Web Services Changes in .NET Framework 1.1

Author: Darshan Singh (Managing Editor,
Last Updated: May 30, 2003
This article as a PDF file (Use this to print the article).

In April 2003, Microsoft released the .NET Framework version 1.1 (v1.1.4322). This article summarizes the changes to XML/Web services support in the .NET Framework version 1.1.

Here is the summary of changes: Let's now look at each of the above points in detail.

HTTP GET and HTTP POST methods for Web services access are disabled by default

The XML Web services written using the .NET Framework 1.0 can be accessed either by sending a HTTP GET request, a HTTP POST request or by sending a SOAP request. I often use MSXML XMLHTTP and ServerXMLHTTP to send GET/POST requests to .NET XML Web services and work with the resultant XML. All such applications broke when I installed .NET Framework 1.1 on the server. For security reasons, Microsoft decided to by default disable GET and POST access to .NET XML Web services, and only allowed SOAP method and HttpPostLocalhost - a new method that allows accessing services using HTTP POST from local machine using http://localhost.

You can enable HTTP GET/POST Web service access methods for a particular virtual root (by updating the web.config for that vroot) or for the entire machine (by updating the machine.config):

Enabling HTTP GET/POST for a particular vroot by updating web.config:
            <add name="HttpGet"/>
            <add name="HttpPost"/>

Enabling HTTP GET/POST for entire machine by updating machine.config:
	<add name="HttpSoap"/>
	<add name="HttpPost"/>
	<add name="HttpGet"/> 
	<add name="HttpPostLocalhost"/>
      <!-- Documentation enables the documentation/test pages -->
	<add name="Documentation"/>
More details on this can be found here.

New web.config element: <supportedRuntime>

Applications created with version 1.1 can specify the supported .NET Framework version(s) using the <supportedRuntime> element(s) within the <startup> element in application configuration file. If your application works with multiple CLR versions, you can include multiple <supportedRuntime> elements, and the order of elements decides the preference.
Like with the <requiredRuntime> element in 1.0, the version attribute value must match the installation folder name for the specified version of the runtime.

Supports 1.1 and 1.0, but prefers 1.1:
    <supportedRuntime version="v1.1.4322"/>
    <supportedRuntime version="v1.0.3705"/>
  . . . 

If you have created an application using version 1.0, then the Framework by default would load CLR version 1.0, even if 1.1 is installed on the machine. But, if 1.0 is not present on the machine, in such cases CLR 1.1 would be loaded. If you want to prevent this behavior, and have the application fail during startup if the 1.0 is not available (assuming application is created using 1.0, but only 1.1 is available on the machine), write the following lines in the application configuration file:

Supports ONLY 1.0:
    <requiredRuntime version="v1.0.3705"/>
    <supportedRuntime version="v1.0.3705"/>
More details on this can be found here.

SoapHeaderAttribute.Required Property is now obsolete

The (ASP).NET Framework 1.0 strictly enforced the presence of a particular SOAP header if the Required property was set to true. It used to raise SoapHeaderException for missing required header. This check is relaxed in .NET Framework version 1.1. First, the SoapHeaderAttribute.Required property is declared obsolete that means it might not be available in future releases; secondly the ASP.NET framework no longer enforces the required header to be present. In your application, you should always check for null reference (Nothing in Visual Basic) header value irrespective of if required property is set to true or not.

More details on this can be found here.

Security-related changes to System.Xml.Xsl.XslTransform class

The .NET Framework supports XSLT 1.0 W3C standard. The XslTransform class (in the System.Xml.Xsl namespace) implements the core XSLT functionality and it can be used to load the stylesheet and apply the transformation.

As part of the code-access security feature in the .NET Framework, the assembly loader gathers information (or Evidence) at load time based on where the code is being loaded from (the zones) as well as the metadata for the assembly itself. You can configure security for each zone by assigning different permissions sets. You can use the built-in permissions sets or define your own. Permission sets are commonly separated into three categories: full trust, partial trust, and untrusted. Full trust doesn't enforce any restrictions on the code this is generally code from local computer or strong named source. Code from intranet and some Internet sources is generally assigned partial permission set; and zones with no specific permissions assigned is treated as untrusted.
The stylesheet can contain external references such as the external URL reference in the document() function; or the script, or the extension objects. Considering this, for security reasons, the designers of .NET Framework version 1.0 disallowed use of XslTransform class in partial trusted code. This means the partial trusted code cannot instantiate XslTransform objects. On the other hand, within full trust code, the stylesheet could do virtually anything (even though stylesheet was loaded from an untrusted source). This implementation, on one side is very restrictive (semi-trusted assemblies not being able to use XSLT functionality), and on the other side, non-secure (stylesheet [loaded from anywhere] inside trusted assembly code could execute scripts, etc.).

Version 1.1 fixes this problem by making following changes:
  • Partial trusted code is allowed to instantiate XslTransform objects.
  • XslTransform.Load overloaded methods now takes an additional parameter of type Evidence, which is used to determine what the stylesheet can do.

    The version 1.0 methods (without the Evidence parameter) are declared obsolete, and if you use those methods, the 1.1 CLR would apply the implicit stylesheet evidence based on from where the stylesheet is being loaded. That means if you have a code that loads XSLT stylesheet from intranet and for example if the stylesheet contains some script code or extension objects, the load might start failing with 1.1, because the Framework now assigned the intranet zone permission set and restricts loading stylesheets containing script code. The solution is to either full trust the URL from where the XSLT is being loaded or get a local copy of the stylesheet.

    The following table is copied from the .NET Framework 1.1 documentation:

    Scenario Type of Evidence to Provide
    The XSLT style sheet has no external references, or the style sheet comes from a code base that you trust. Provide the evidence from your assembly:

    [Visual Basic]
       Dim xslt = New XslTransform()
       xslt.Load(stylesheet, resolver, Me.GetType().Assembly.Evidence)
       XsltTransform xslt = new XslTransform();
       xslt.Load(stylesheet, resolver, this.GetType().Assembly.Evidence);
    The XSLT style sheet comes from an outside source. The origin of the source is known and there is a verifiable URI. Create evidence using the URI.

    [Visual Basic]
       Dim xslt As New XslTransform()
       Dim ev As Evidence = XmlSecureResolver.CreateEvidenceForUrl(stylesheetUri)
       xslt.Load(stylesheet, resolver, evidence)
       XslTransform xslt = new XslTransform();
       Evidence ev = XmlSecureResolver.CreateEvidenceForUrl(stylesheetUri);
       xslt.Load(stylesheet, resolver, evidence);
    The XSLT style sheet comes from an outside source. The origin of the source is not known. Set evidence to a null reference (Nothing in VB). Script blocks are not processed, the XSLT document() function is not supported, and privileged extension objects are disallowed.

    Additionally, you can also set the resolver parameter to a null reference (Nothing) This ensures that xsl:import and xsl:include elements are not processed.

    The XSLT style sheet comes from an outside source. The origin of the source is not known, but you require script support. Request evidence from the caller.

  • The XslTransform.XmlResolver property is declared obsolete. This property is used during transformation for things like resolving the document() function.

    In version 1.1, a new parameter of type XmlResolver is added to the XslTransform.Transform method. Microsoft recommends passing the XmlResolver to the Transform method rather than using the XmlResolver property, as XmlResolver is not cached after the Transform method completes. If XmlResolver parameter is a null reference (Nothing in Visual Basic), the document() function is not resolved.
More details on this can be found here.

System.Web.Services changes

The following table summarizes the changes to classes in the System.Web.Services namespace:
Class Changes
Protocols.HttpSimpleClientProtocol, Protocols.HttpWebClientProtocol, and Protocols.SoapHttpClientProtocol

A new property:
   public bool UnsafeAuthenticatedConnectionSharing {get; set;}
Default value: false
When you set it to true, .NET Framework classes re-use previous server connections for authentication.
Related KB Article: NTLM Authentication Is Lost on Every Call
The class is no longer sealed and includes following new property:
   Property: SoapHeaderFaultBinding Fault { public get; public set; }
Controls the output in a WSDL document for the headerfault XML element of a SOAP header.

Description.SoapProtocolImporter The class is no longer sealed and includes following new method:
   protected virtual bool IsSoapEncodingPresent (string uriList)
This member supports the .NET Framework infrastructure and is not intended to be used directly from your code.

Protocols.SoapClientMessage, and
A new property:
   string ContentEncoding { public get; public set; }
Gets or sets the contents of the Content-Encoding HTTP header. A SOAP extension can set the ContentEncoding property to provide supplementary information about the encoding of a SOAP message without changing the media type as expressed in the Content-Type HTTP header.

Protocols.SoapHeaderAttribute Required property is declared obsolete - and will be removed in future.

Protocols.SoapHeaderDirection This enum includes a new entry: Fault = 4 (in addition to existing In = 1, Out = 2, and InOut = 3). Specifies the SoapHeader is sent to the XML Web service client when an exception is thrown by the XML Web service method.

System.Xml changes

The following table summarizes the changes to classes in the System.Xml namespace:
Class Changes
XmlException Following new constructor overloads are added:
   public XmlException ()
   public XmlException (string message)
   public XmlException (string message, 
              Exception innerException, int lineNumber, 
              int linePosition)

XmlNodeReader and XmlValidatingReader

Methods ReadInnerXml and ReadOuterXml are now declared as virtual.

XmlReader and XmlTextReader

Methods ReadInnerXml, ReadOuterXml, and ReadString are now declared as virtual.

XmlResolver and XmlUrlResolver Method ResolveUri is now declared as virtual.

Also, the 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.

XmlResolver is generally used to locate external resources such as external DTDs, entities, and schemas; or to load any stylesheets referenced in xsl:import and xsl:include elements. Click here for more information.

XmlSecureResolver (New class) From the .NET Framework 1.1 documentation:
XmlSecureResolver Allows you to secure another implementation of XmlResolver.

XmlSecureResolver wraps around a concrete implementation of XmlResolver, and restricts the resources that the underlying XmlResolver has access to. For instance, XmlSecureResolver has the ability to prohibit cross-domain redirection, which occurs from an embedded URI reference.

When you construct an XmlSecureResolver object, you provide a valid XmlResolver implementation along with a URL, an instance of Evidence, or a System.Security.PermissionSet, which is used by the XmlSecureResolver to determine security. Either a PermissionSet is generated or the existing one is used and PermitOnly is called on it to secure the underlying XmlResolver.

Schema.XmlSchema A new member - Overloaded Compile method:
   public void Compile(ValidationEventHandler, XmlResolver);
The added XmlResolver parameter is used to resolve namespaces referenced in include and import elements.

Schema.XmlSchemaCollection Two new members - Overloaded Add methods:
   public XmlSchema Add (string ns, XmlReader reader, XmlResolver resolver);
   public XmlSchema Add (XmlSchema schema, XmlResolver resolver); 
The added XmlResolver parameter is used to resolve namespaces referenced in include and import elements.

Serialization.XmlMemberMapping A new property:
   bool CheckSpecified { public get; }
XmlMemberMapping supports the .NET Framework infrastructure and is not intended to be used directly from your code.

Serialization.XmlSerializationReader Three new methods:
   protected Exception CreateCtorHasSecurityException (string typeName)
   protected Exception CreateInaccessibleConstructorException (string typeName)
   protected XmlDocument ReadXmlDocument (bool wrapped)
And a new property:
   protected bool IsReturnValue
XmlSerializationReader supports the .NET Framework infrastructure and is not intended to be used directly from your code.

Serialization.XmlSerializationWriter Three new methods:
   protected Exception CreateChoiceIdentifierValueException 
        (string value, string identifier, string name, string ns) 
   protected Exception CreateInvalidChoiceIdentifierValueException 
        (string type, string identifier)
   protected void WriteRpcResult (string name, string ns)
XmlSerializationWriter supports the .NET Framework infrastructure and is not intended to be used directly from your code.

Other miscellaneous changes

Backwards Breaking Changes from version 1.0 to 1.1
Forwards Breaking Changes from version 1.0 to 1.1
  • In .NET Framework version 1.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.
    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.

  • In .NET Framework version 1.0, fully-trusted users had the potential to take an XsltArgumentList from semi-trusted users and execute the enclosed extension objects under their security, essentially an elevation of privileges. For .NET Framework version 1.1, we are restricting the ability to add extension objects to fully-trusted code.

  • In the .NET Framework version 1.0, if an <xsd:all> tag has minOccurs="0", then all of the elements within the group become optional. This is not valid according to W3C specification. The new behavior is to throw a validation error if the elements within the group that have minOccurs="1" do not appear in the content.

  • The ReadInnerXml() method is documented to validate the XML against the supplied schema (like the Read() method does). It did not in .NET Framework version 1.0, so we fixed this, and user could get validation errors thrown now (as they would expect) when reading XML that does not conform to the schema.

  • WSDL.exe now generates proxies that honor schemas defining parameters such as: minOccurs=0 or: use=optional.

    A documented feature of the past version of ASP.NET was support for services exposing operations with optional simple type parameters. These optional parameters were to be identified by: minOccurs=0 or: use=optional, and should have resulted in the generation of proxy methods with two parameters per optional parameter. This additional parameter is used to specify whether the parameter was passed in the WebMethod invocation. Unfortunately, there was a bug which prevented this feature from being realized. Thus, all optional parameters are treated as required by WDSL.exe.

    This issue is addressed in this release, resulting in a change in how proxies are generated. Proxies will now have the intended two parameters per optional parameter. This might cause issues should the proxy is ever be regenerated, as it will contain one additional parameter per optional parameter.

  • Schemas that contain maxOccurs=0 in .NET Framework version 1.0 incorrectly throws an NullReference exception. The input file contains an element like: <xsd:element ref="imp:impElem1" minOccurs="0" maxOccurs="0"/> In .NET Framework version 1.0, ReadXmlSchema incorrectly throws NullReferenceException. In version 1.1, System.Data correctly ignores maxOccurs=0 elements. Your application will not run as expected on version 1.0 if your application depends on version 1.1 behavior. When DataSet is serializing the XML, the maxOccurs node represents a non-existent column.

  • System.Security.Cryptography.Xml classes (SignedXml, Transform, XmlDsigBase64Transform, etc.) contain a new member, a property XmlResolver Resolver { public set; }, which is used to resolves external resources named by a URI.

  • A new class AspNetHostingPermission contains methods (ToXml and FromXml) that allow converting security object and it's current state into XML format and then reconstructing a security object with a specified state from an XML encoding. Similarly, another new class OdbcPermission has ToXml and FromXml methods.

  • The namespace System.EnterpriseServices.Internal includes new classes ( SoapClientImport, SoapServerTlb, SoapServerVRoot, and SoapUtility ) and defines some new interfaces ( ISoapClientImport, ISoapServerTlb, ISoapServerVRoot, and ISoapUtility). Check .NET Framework 1.1 documentation for more details on these new classes and interfaces.

  • The namespace System.Runtime.Remoting contains a new classes SoapServerFormatterSink and SoapServerFormatterSinkProvider. Check .NET Framework 1.1 documentation for more details on these new classes.

  • The SoapFormatter class in the System.Runtime.Serialization.Formatters.Soap namespace contains a new property FilterLevel that can be used to control the current automatic deserialization level in .NET Remoting.

  • Looks like .NET Framework has a nasty bug in HTTP access classes. If you use System.Net classes such as HttpWebRequest and try send the request to a remote HTTP server; or use XmlDocument to load a remote XML document or use XmlTextReader to do the same thing, with 1.1 you'll get the following exception:
    An unhandled exception of type 'System.Net.Sockets.SocketException' occurred in system.dll
    Additional information: An operation on a socket could not be performed because the 
    system lacked sufficient buffer space or because a queue was full
    For example, the following code would work in 1.0 but fail in 1.1:
    XmlDocument xmlDoc = new XmlDocument();


The goal of this article was to summarize XML/Web services related changes in the latest .NET Framework (version 1.1) release. While developing .NET XML application, you can consider this article as a quick reference whenever you want to find out what has changed in Framework version 1.1.
  Contact Us | E-mail Us | Site Guide | About PerfectXML | Advertise ©2004 All rights reserved. | Privacy