.NET XmlValidatingReader

Factual Questions
1

The following is not PHP code, rather C# (the PHP tags colourize C# pretty nicely, no?) I didn’t write it, but I gotta fix it. (comments, try…catch… other unnecessaries removed for your viewing pleasure)


class Class1
{
  [STAThread]
  static void Main(string[] args)
  {
    XmlDocument doc = new XmlDocument();
    doc.Load(@"c:\doc.xml");

    XmlTextReader textReader = new XmlTextReader(@"c:\schema.xsd");         
    XmlSchema xsd = XmlSchema.Read(textReader, new ValidationEventHandler(XMLValidationErrorHandler));
    textReader.Close();

    XmlValidatingReader mvr = new XmlValidatingReader(doc.OuterXml, XmlNodeType.Document, null);
    mvr.Schemas.Add(xsd);
    mvr.ValidationType = ValidationType.Schema;
    mvr.ValidationEventHandler += new ValidationEventHandler(XMLValidationErrorHandler);

    while(mvr.Read());

    Console.WriteLine("All is well");
    Console.ReadLine();
  }

  static private void XMLValidationErrorHandler (object sender, System.Xml.Schema.ValidationEventArgs e)
  {
    throw new Exception(e.Message);
  }
}

My question: Why the hell does this work fine on the developer’s machine but not on our test server?

Details:
Developer workstations: XP SP2
Test server: Win2K3

Each has .NET Framework v1.1.4322, (and v1.0.3705) and the app is compiled against v1.1

On the test server, the call to mvr.Read() throws an InvalidOperationException: “The operation is not valid due to the current state of the object.”

The only difference I’ve found: Test server has MSXML v4.20.9818.0 and DevWS has MSXML v4.10.9404.0. There’s a mountain of red tape to make any changes to the Test Server, so before I wade through it to sync the versions: can this be the explanation? We’re not using the MSXML components, but do the .NET classes sit on top of it? (I thought they were ground-up stand-alone?)

2

That’s a wierd one alright. The only thing I can think of right off is rights. That is, does the .NET process have the proper rights to the file being read?

Further, if this is an ASP.NET application then you must also account for the version of IIS that is running as well as the OS. I’m currently working on an ASP.NET app on my work machine that’s running IIS v6 on Windows XP. Our hosted server is running IIS v5 on Win2003. The “user” rights that are required are different for the two machines.

3

Rights/permission was high on my list too. The acutal system has a highly complex architechture (Web Service calls BizTalk orchestration, calls a series of components, SQL Server, Oracle, blah blah blah). Multiple services, running as multiple users, Windows ACL, database ACLs, yada yada yada.

To avoid the clutter, I excerpted the above logic into the teeny console app above. This reproduces the behaviour without all the hassle. The app runs as the user logged on - Administrator privileges in both cases, with Full control on all files/folders. By denying rights, the exception thrown is “Access denied.”

4

I changed while (messageValidatingReader.Read()) to the following


int count = 0;
while (messageValidatingReader.Read())
{
  Console.WriteLine("Successfully read {0} times", ++count);
}

On the dev box it runs successfully 124 times. On the Test Server only 3 (failing on the fourth read, I presume).

Further: A developer has recently left. To avoid changing my machine, I’ve am using his as an experimental (change the MSXML, for e.g.)

BUT, turns out although his machine is XP SP2 as is mine, his version of MSXML is the same as the Server’s. AND the above test app behaves the same way as it does on the server.

HOWEVER, I ran procexp, as well as removed MSXML altogether - both confirm the MSXML version is a red herring.

FINALLY, when I first got on his machine I was not an administrator. The app failed. I had tech upgrade me to administrator. The app still failed.

Arrgghhh… (I’m getting ready to Pit Microsoft!)

5

For those who may be interested: Found the problem. Our BizTalk development team were the first to receive a number of .NET framework hotfixes. Tech upgraded only our dev boxes, but hadn’t yet swam through the red tape to apply them to the servers (nor told the dev team about any of this).

This is the specific problem solved by one of the hotfixes.

Thanks Ponder Stibbons for your time, and for anyone else who may have mulled over the problem.