Unrecognized attribute 'xmlns'
-
I tried to deploy an ASP.NET 2.0 project on a computer with only ASP.NET 1.1 installed. Okay, error between keyboard and chair, I shouldn't expect it to work; however, the error message I got when trying to view the website amused me quite a bit.
Configuration Error
Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.
Parser Error Message: Unrecognized attribute 'xmlns'.
Source Error:
Line 1: <?xml version="1.0"?>
Line 2: <configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
Line 3: <configSections>
Line 4: <section name="microsoft.web.services2>It's saying that, in an XML file (the web.config), the attribute xmlns is not recognized. This is funny because that attribute is supported by every XML document. It's the XML namespace for that element. It's fairly important to any non-trivial XML implementation.
I'd understand if it didn't recognize that particular namespace, since it's newer than the version of ASP.NET installed; but the error seems to indicate clearly that the attribute itself is not recognized.
Microsoft has been such an advocate of XML since its introduction, yet somehow this doesn't surprise me.
-
This is pure WTFery... I can see it now - MS roll out IE8 as a critical update and someone finds out it produces a critical exception: "unrecognised attribute: href: possible hack attack, there was a link on the page to a non-IIS-hosted website!!!"
-
[quote user="joe.edwards@imaginuity.com"]
It's saying that, in an XML file (the web.config), the attribute xmlns is not recognized. This is funny because that attribute is supported by every XML document. It's the XML namespace for that element. It's fairly important to any non-trivial XML implementation.
[/quote]
Well, namespaces are defined in a different specification from XML itself. An application that doesn't recognise namespaces is perfectly acceptable standards-wise, although quite possibly less useful than one that does.
-
[quote user="iwpg"][quote user="joe.edwards@imaginuity.com"]
It's saying that, in an XML file (the web.config), the attribute xmlns is not recognized. This is funny because that attribute is supported by every XML document. It's the XML namespace for that element. It's fairly important to any non-trivial XML implementation.
[/quote]
Well, namespaces are defined in a different specification from XML itself. An application that doesn't recognise namespaces is perfectly acceptable standards-wise, although quite possibly less useful than one that does.
[/quote]
Sure, but XML Namespaces was originally drafted in 1999. Surely .NET isn't older than that.
Another thing to consider: have a look at the original draft of the XML Namespaces specification. Search for the name Andrew Layman. That's right, Microsoft helped write the spec, back in 1999.
-
I'd say - no wtf here - at least not the described one. You supplied wrong binary for wrong source. Maybe recognising attributes involves browsing through callbacks and some were with unknown type (generics? new types?) were ignored? (blind shot)
It's situation, like checking if you can access System.String by browsing reflections of classes, but in try block, to verify, that you can access reflection, but in monitored child process to check if you can "try", but with......... You just don't do that and expect your environment to be complete.
On the other hand - not forcing source to be marked with version of .NET it's made for, is just crazy... It should be not compatible version error from the beginning.
-
[quote user="VGR"][quote user="iwpg"][quote user="joe.edwards@imaginuity.com"]
It's saying that, in an XML file (the web.config), the attribute xmlns is not recognized. This is funny because that attribute is supported by every XML document. It's the XML namespace for that element. It's fairly important to any non-trivial XML implementation.
[/quote]
Well, namespaces are defined in a different specification from XML itself. An application that doesn't recognise namespaces is perfectly acceptable standards-wise, although quite possibly less useful than one that does.
[/quote]
Sure, but XML Namespaces was originally drafted in 1999. Surely .NET isn't older than that.
Another thing to consider: have a look at the original draft of the XML Namespaces specification. Search for the name Andrew Layman. That's right, Microsoft helped write the spec, back in 1999.
[/quote]
.NET has been around since before 1999, though maybe not released. I remember playing around with it at one of my earlier contracts at Microsoft.
-
[quote user="viraptor"]
I'd say - no wtf here - at least not the described one. You supplied wrong binary for wrong source. Maybe recognising attributes involves browsing through callbacks and some were with unknown type (generics? new types?) were ignored? (blind shot)
It's situation, like checking if you can access System.String by browsing reflections of classes, but in try block, to verify, that you can access reflection, but in monitored child process to check if you can "try", but with......... You just don't do that and expect your environment to be complete.
On the other hand - not forcing source to be marked with version of .NET it's made for, is just crazy... It should be not compatible version error from the beginning.
[/quote]
Heh, cool. I haven't seen any good Dissociated Press output in a long time. Thanks!
-
surely the WTF is just that the error message is badly written - i would have assumed they are trying to communicate the fact that the value/contents of the xmlns attribute was not recognised (being a .NET 2.0 namespace when it was expecting a 1.1 instead...) although that should be something like "Invalid 'xmlns' attribute" really.
-
This is not a WTF at all. The application was expecting a file with a particular schema. The schema it was expecting does not have an attribute named 'xmlns' on the <configuration> element. There is no spec in the world that says that when my application is parsing its own configuration file that I'm supposed to handle attributes that aren't a part of my schema. If the document I'm parsing doesn't validate against my schema I'm totally within my rights to throw an error.
-
This happened to me, same error. I'm working pretty consistently between a few sites simultaneously, all running as virtual roots off my c:\inetpub\wwwroot folder. Somwhere along the line, some configuration or site setup process installed a web.config in my wwwroot folder with this xmlns attribute added to the root node.
My application was running off a virtual directory at: http://localhost/clientroot
I didn't need this web.config file in the wwwroot b/c i'm not running any apps off that folder directly. They're all virtual directories off the wwwroot. I deleted the web.config in my wwwroot folder, and my problem dissipated. I was then able to run and debug my "clientroot" project properly in VS2003.
The thing that clued me off to this was that I was attempting to load my clientroot project in VS2003 and debug it. The url in my browser was http://localhost/clientroot, but the error message that came up noted a problem with web.config located in c:\inetpub\wwwroot. This told me there was some sort of configuration issue with IIS running the web.config in the root folder, not my project folder.
