I got this error when calling a C# web service from javascript. With a message like that, you'd think there was a problem with the Content-Type on my HTTP request.

Using the fine LiveHTTPHeaders Firefox extension, I saw in the headers:

After a bit of hunting, I found the problem. My web service had an int parameter, and I was passing in 't1245'. That caused a casting error, which .NET cleverly reported back as a problem with the content-type.

Moral of the story: make your error messages meaningful.

So, I'm still working with XML generation, and I discovered an interesting design choice made by the writers of XmlSerializer. My efforts from yesterday were so I could use the XmlSerializer to generate flawless XML from C# objects, without going through the bother of string manipulation. The XML it generates is well-formed, but it was leaving off an attribute ("Version"), and I wasn't sure why. I googled around and found another dev with the same problem. Craig Andera's post "DefaultValue and XmlSerializer Don't Mix?" has a quick reproduction.

If you have an attribute with a default value defined in the DTD/XSD, and the C# variable representing that attribute has that value, then the XmlSerializer chooses not to render the attribute. Anyone reading the XML must be using the same DTD/XSD, and they already know the default value, so why waste bandwidth/space by rendering that attribute?

Well, when the reader of my XML is using that missing "Version" attribute as a key for how it should process my XML, it makes a big difference. Based on the error message from the vendor, I think they are switching on that "Version" to pick a DTD, then validating against that and processing the request. It would be nice to have some kind of "RenderDefaultAttributesAnyway" flag I could set before serializing. In the end I just changed the DTD to remove the default value, and all was well.

I've started to implement a web service, sending and receiving XML snippets to a vendor. I was browsing their documentation, and was about to start throwing together some code using string functions to build/parse the XML, and then I remembered all the hubub I've heard about generating code using XML files, and figured there might be some tools out there to make this go a lot smoother. The vendor was kind enough to provide a sample XML file and a Document Type Definition (DTD) file, so now all I need to do is convert that to C# classes.

First try: xsd.exe

The first tool I looked at was xsd.exe , a command line tool bundled with Visual Studio. When I dug in, I see that it can:

• convert a XML Schema Definition (XSD) file into C# classes
• convert a sample XML file into a XSD file, inferring and guessing as to the details
• convert an External Data Representation (XDR, what the hell is that one?) file into a XSD file, inferring and guessing as to the details
• generate XSD files for .NET classes in a file or assembly

Second try: dtd2xs and xsd.exe

The first hit was dtd2xs. This is a Java based converter that can be run from the commandline, used as a library in java programs, and as an applet in webpage. It convienently comes with some HTML that already has the applet set up, so I loaded up that page and tried to convert my DTD. After a few seconds, I was presented with a window listing some debug info, and then a line with:

Third try: Visual Studio

Next, I tried to use the XSD editor in Visual Studio to see if I could correct the problem. I messed around with the raw XML of the XSD file, guessing what attributes like "ref" and "name" would mean in the context of defining data. After messing around with the file, I was able to generate even less sensical errors from xsd.exe. Had I put in the time to learn the XSD XML dialect, then I'm sure these errors would make sense, but I've no interest in learning more XML acronyms. There's enough of those in my head already. I decided to try to build it from scratch using Visual Studio's GUI XSD editor.

I dragged an "element" block from the toolbox, added some attributes, and then promptly gave up. The UI wasn't that great (few tooltips, ambiguous context menu options), and it wasn't clear how to do what should be simple things. I figure if I'm going to spend time learning how to use a tool, I'd rather use one that will be more efficient, so I'll put my effort into the command line tools.

Fourth try: xsd.exe again

I decided to take a different approach:

1. use xsd.exe to generate an XSD from my sample XML file.
2. use xsd.exe can generate C# from that XSD.

Fifth try: Xsdvalid and xsd.exe

The next converter I found was Xsdvalid. This is a sub-component of a larger XML editor, XMLmind XML Editor. Xsdvalid is another Java program (I guess Java folks love XML), able to be used as a library or from the command line. I ran my DTD through it, and it came out with a much larger XSD than dtd2xs. xsd.exe ran without errors on the first try, and the resulting C# had enums for the enumerations defined in the DTD, and seemed a lot better. My C# is now directly based on the vendor's definition, with no opportunity for me to make mistakes in translating.

Conclusion

I haven't actually used the generated code yet, but will be writing some unit tests momentarily for parsing/building. I do have high hopes, so bless you people with XML fetishes for doing this work for me. Also, curse you people with XML fetishes for not picking *one* XML dialect to describe XML documents and causing this task in the first place.

I've now gotten permission to use XUL for another client, and this time around, I'm trying it a little differently.

Rather than serving up a .xul file, and doing everything with overlays, DOM manipulation, and XBL, I'm serving up a .aspx file, setting its content-type to application/vnd.mozilla.xul+xml, and then using ASP.NET to render XUL instead of HTML. Jeb (do you have a link, Jeb?) said he was creating XUL apps this way using JSP, so I figured I'd give it a try. So far I like it. This method lets me lean on my ASP.NET skills while I build up the XUL skills.

How I have it set up:

• One .aspx page per XUL layout, using <html:a> tags to navigate between them.
• One ASP.NET user control is on each page, ensuring all XUL layouts have the same template and include the same javascript and css files. I had tried do this with overlays, but didn't have much luck.
• A few IHttpHandlers to send RDF to my XUL, and JSON to my javascript.
• A few webservices that get called by my javascript, and the work is done in C#.

For now, I'm only using this on applications that require windows authentication to access the site, so to access the web services you'll need to be logged in. Security is still a concern, though, and eventually I'll have to expose some of these web services to wild. I've been considering some token system where the server passes a token to the client when it renders the xul aspx page, and then the javascript passes that token to the web services, but I haven't fleshed anything out yet.

I have a public static readonly string, and I want to use it as a case in a switch statement, as above. Unfortunately for me, C# doesn't think a public static readonly string is a constant value. I guess it's not constant, as it changes from its compile time value (null?) to its runtime value ("bar") once it gets referenced. This is retarded. What if I wanted to store constant values in the web|app.config? Those aren't determined until runtime when I pull them out of ConfigurationSettings.AppSettings.

Oh wait, that is such a time-saver! Now I don't have to even consider solutions using runtime constants in case statements. Thanks, C# language developers, you've limited my options once again, steering my foolish code down the path you know is best!

It's been awhile since I wrote the walkthrough, and I've come across a few more problems and solutions. Most of the walkthrough still applies, but here are two tips to make it even easier.

Connection string management

The connection string for ADONetAppenders is set in the web.config. You usually also have a connection string specified elsewhere for the rest of your application to use, and having to specify it again is a little nasty, but not too bad. The real problem is when you have a dev/test/live database setup. You probably already have some system for swapping your main connection string. The solution is to set the log4net connection string on initialization, and ignore the one specified in web.config.
Instead of just calling:

Creating your loggers with less typing

Typing:

It saves having to find the classname every time you declare log. Reflection will mean slight performance degradation when the static initializer executes but in most apps this is insignificant.

tells the driver to always read "intermixed" data columns as text

1. NDoc is a tool for generating HTML or CHM documentation based on the XML comments in your code. It's very similar to Javadocs, and can even generate HTML in that style. I've been using this one in a few places for a little while. Their GUI is very easy to use, and their command-line utility has good documentation.
2. NUnit is a unit testing framework written in C#. The idea is you write a lot of small, atomic tests, and then at any point in development you can make a huge change and run your tests to find out where you screwed up. NUnit has the concept of TestFixtures, which is an attribute you add to any class you want to run test in. You slap that attribute at the top, then make your tests, giving them the Test attribute, and away you go, it uses reflection to figure out the rest.
3. NAnt is a build system that is a replacement for makefiles. It lets you specify targets and such like makefiles. This is by far the most complicated of the three, but it still only took a half day to get it to do what I wanted.