.NET XML KB Articles
FIX
Visual Studio .NET Cannot Open Existing ASP.NET Projects After You Install Internet Protocol Version 6 on Windows XP
KB: 818262 |
After you install Internet Protocol version 6 (IPv6) on a computer running Windows XP, Visual Studio .NET cannot open existing ASP.NET Web projects. When you try to open an ASP.NET project, you may receive following error message:
Unable to open Web project 'ProjectName'. Unable to validate that the file path 'c:\inetpub\wwwroot\webasp10' matches the URL path 'http://localhost/ProjectName'. A connection with the server could not be established
To resolve this problem, install Windows XP Service Pack 1 on the computer running on Windows XP, and then install Visual Studio .NET. In IPv6 scenarios, critical functions such as opening and creating Visual Studio .NET projects, may fail if the service pack is not installed.
|
WSDL Tool Cannot Generate Web Service Proxies in Visual J# .NET
KB: 815258 |
|
When you use the Wsdl.exe tool (WSDL) to generate a Web service proxy in a specific language by using the /l or /language switch, you cannot specify the language for Microsoft Visual J# .NET. The language option permits you to specify CS for Microsoft Visual C# .NET, VB for Microsoft Visual Basic .NET, and JS for Microsoft JScript .NET. However, no value is available for Visual J# .NET. Therefore, you cannot generate the proxy file in Visual J# .NET.
|
'Unable to generate a serializer' Error When You Drag a User Control onto a Form
KB: 815251 |
In Microsoft Visual Studio .NET, when you drag a user control onto a form, and the user control consumes a Web service with a Web Service method that has a Typed DataSet as a parameter or as a return type, you receive the following error:
Unable to generate a serializer for type UserControlName.WebServerName.DataSetName from assembly because the assembly may be dynamic. Save the assembly and load it from disk to use it with XmlSerialization.
You receive the error only if the user control instantiates the Web service when you drag the user control onto the form.
To use Typed DataSets, the XML Serializer must have additional serialization information about the Typed DataSets schema. When you create a Web service with a Web Service method, and you have a Typed DataSet as a parameter or as a return type, the serialization information is built into the Web service. When you add a Web Reference to this Web service in a user control project, the serialization information is built into the auto-generated Web Service Proxy file. However, when the user control is added to the toolbox in a project, the project has no reference to the Proxy file. Therefore, Visual Studio .NET cannot obtain the serialization information for the Typed DataSet. Without this serialization information, you receive the error mentioned in the "Symptoms" section of this article.
 |
Qualified Attributes in XML Schemas Do Not Serialize Correctly
KB: 327071 |
|
Qualified attributes in an XML schema do not result in the correct declarations in the XSD or WSDL-generated code.
|
Null Values Are Returned for Fabricated DataColumns When a DataSet Is Deserialized from a DiffGram
KB: 325697 |
|
When you deserialize an ADO.NET DataSet from XML in the DiffGram format, null values are returned for fabricated DataColumns whose values are computed by using aggregate functions with expressions that reference columns in a child DataTable. The DiffGram XML format is the default format that is used to serialize ADO.NET DataSet objects across process boundaries. ASP.NET Web Service and Microsoft .NET Remoting clients might experience this behavior when they consume (that is, deserialize) and access the data in a DataSet that a server component serializes and returns as a DiffGram.
|
Document Function in XSLT Style Sheet Does Not Raise a .NET Exception
KB: 325692 |
|
With the document() XSLT function, you can retrieve other XML resources from an XSLT style sheet in addition to the initial data that the input stream provides. The .NET Framework XSLT processor does not raise any exception when it cannot resolve a document() reference in an XSLT style sheet to an external XML resource. The XSLT transformation completes successfully and the result that is generated is not as you expect.
|
NTLM Authentication Is Lost on Every Call
KB: 323683 |
If you are hosting in Microsoft Internet Information Services (IIS) and if you are using NTLM authentication, .NET remoting opens and closes the connection on every call. Because of this, each call must authenticate itself for security reasons and to make sure that no one can hijack the connection. However, NTLM performance is slower when you make multiple calls.
This fix adds a boolean property named UnsafeAuthenticatedConnectionSharing to the HttpWebRequest class to improve the performance of NTLM authentication.
|
Add Method of the DataRowCollection Does Not Reflect Changes in XmlDataDocument View
KB: 320849 |
The "Synchronizing a DataSet with an XmlDataDocument" Microsoft Developer Network (MSDN) topic has the following information:
The .NET Framework enables real-time, synchronous access to both the relational and hierarchical representations of data through the DataSet object and the XmlDataDocument object, respectively.
When a DataSet is synchronized with an XmlDataDocument, both objects are working with a single set of data. However, if new rows are added to the DataSet by using an object array, the DataSet and XmlDataDocument objects are not synchronized. The new rows cannot be seen in the XMLDataDocument object.
Use the DataRow object instead of an object array to add new rows to the DataTable. This produces the expected behavior and both DataSet and XMLDataDocument objects are synchronized as expected.
Microsoft has confirmed that this is a bug in the Microsoft products that are listed at the beginning of this article. This bug was corrected in Microsoft ADO.NET (included with the .NET Framework) 1.1, and Microsoft .NET Framework Class Libraries 1.1 .
|
System.InvalidOperationException If You Use XslTransform in Multithreaded Scenario
KB: 320011 |
If you share an XslTransform object from the System.Xml.Xsl namespace between multiple threads, you may receive the following error message when you build your application:
System.InvalidOperationException: Collection was modified; enumeration operation may not execute. The call stack may appear as follows:
at System.Collections.ArrayListEnumeratorSimple.MoveNext()
at System.Xml.XPath.XsltFunction.SetXsltContext(XsltContext context)
at System.Xml.XPath.CompiledXpathExpr.SetContext(XmlNamespaceManager nsManager)
at System.Xml.Xsl.Processor.GetValueQuery(Int32 key)
at System.Xml.Xsl.Processor.ValueOf(ActionFrame context, Int32 key)
at System.Xml.Xsl.ValueOfAction.Execute(Processor processor, ActionFrame frame)
at System.Xml.Xsl.ActionFrame.Execute(Processor processor)
at System.Xml.Xsl.Processor.Execute()
at System.Xml.Xsl.XslTransform.Transform(IXPathNavigable input,XsltArgumentList args, TextWriter output)
This problem has only been seen to occur on computers that have more than one processor, although it is possible that this problem may also occur on a single processor computer.
This problem occurs because of a bug in the System.Xml.dll assembly.
|
Cannot Step Into a Managed Extensions for C++ WebMethod by Using Visual Studio .NET Debugger
KB: 318617 |
|
When you debug a Managed Extensions for C++ Web Service WebMethod from a client application, you may not be able to step into the WebMethod (also called Causality Stepping). The debugger may step over the WebMethod. This behavior occurs when the WebMethod contains certain types as parameters (for example, String *, __int64[]). Place a breakpoint inside the WebMethod.
|
The xsl:number Element Generates an Exception Error When the Format Pattern Is Set to "A.1"
KB: 318360 |
When the format pattern is set to "A.1", xsl:number generates the following exception error message:
An unhandled exception of type 'System.ArgumentOutOfRangeException' occurred in mscorlib.dll
Additional information: Index was out of range. Must be non-negative and less than the size of the collection.
This bug was corrected in Microsoft .NET Framework Class Libraries 1.1.
|
XML Input File Erased When You Use Transform Method of XslTranform Object
KB: 318143 |
This bug was corrected in P1. When you use the Transform method of the XslTransform object, you may receive the following System.IO.IOException error message, and the original input file is empty:
An unhandled exception of type 'System.IO.IOException' occurred in system.xml.dll The process cannot access the file "filename" because it is being used by another process.
|
User Credentials Leak When You Use Web Services Command-Line Tools
KB: 318099 |
|
When you use the Web Services Description Language Tool (Wsdl.exe) or the Web Services Discovery tool (Disco.exe) to specify credentials, such as your user name and password, from the command line, a credentials leak may occur.
|
Web Services Methods Fail When Invoked from Digest Authenticated Applications
KB: 318062 |
When you enable a Digest authentication for a Web Service in Internet Information Server (IIS) 5.0, the following error is returned:
HTTP 401.4 - Unauthorized: Authorization denied by filter
This bug will be fixed in Windows 2000 Service Pack 3.
|
XmlSchema Object Incorrectly Permits Invalid Local Elements in an XSD Schema
KB: 317415 |
|
If an XSD schema has invalid local elements, the XmlSchema object loads the invalid elements as valid and does not generate an error. This bug was corrected in Microsoft .NET Framework Class Libraries 1.1.
|
|
|
