In Traction

Theme by Anders Norén

Tag: .net

Annoyances while creating Visual Studio projects for Uiml.net

I am currently moving Uiml.net towards MSBuild files (a.k.a. Visual Studio project files) and experienced a few problems such as a restriction with Compact .NET’s OpenFileDialog.

After a bit of Googling, I finally know why I can’t seem to get the OpenFileDialog to look for files in \Program Files: it was just designed that way (do a quick search for OpenFileDialog on that page). Apparantly they wanted to help users organize their files, by restricting them to the \My Documents folder. Too bad they didn’t think of what developers might want to do … I want to allow people to try UIML examples when they click the “Select UIML file” button. Of course these files reside in the Uiml.net application directory itself, so I need to allow them to pick a file outside of the My Documents folder. If that wasn’t bad enough, it further restricts you to one level of subfolders within the My Documents folder!

I also noticed MSBuild has no nice way of copying a file to another path than the one it is being referenced from. I orginally wanted to copy the front-end files and vocabularies in the root directory where the Uiml.net executable is placed. Since I didn’t find a solution, I made dedicated directories for these files, and modified the code to look for them in those directories instead.

If I could tell MSBuild to copy a file to another path, I could also solve the OpenFileDialog problem just by copying the Uiml.net examples to the My Documents folder, while the rest of the application would stay in the Program Files folder.

So my (hackish) solution is now to copy all examples first into a direct subfolder of the user’s My Documents folder. Not very elegant, but it works.

XML sit-ups with .NET

I’m currently writing some C# code that outputs RDF/XML from a set of classes, and came across some annoyances regarding .NET’s support for XML namespaces (or the lack thereof).

First of all, .NET has only explicit support for one namespace per element. Additional namespaces must be specified by adding an extra xmlns attribute yourself. Well, that’s not so bad, but it adds to the code bloat.

When you want to use namespaces to create new elements (e.g. rdf:Description), you have to explicitly pass the namespace URI again. Otherwise the prefix (in this case rdf) will be ignored. It would be helpful if .NET could check to see if the prefix corresponds to any namespace previously specified in the document root.

Okay, I could have used an RDF library, but this was supposed to be a quick hack, so I didn’t have time to learn another library.

I can’t help but think that if I would have just used strings instead of the System.Xml classes, the program would have been finished sooner. Come to think of it, I should have known better and just used N3 or Turtle.

When using .NET’s XML classes, it seems like half of my code is redundant. Man, do I miss Ruby‘s XML Builder.

I’ll end with a great graphic by Why the Lucky Stiff, in which he compares using XML to doing annoying sit-ups:

XML situps

The term XML sit-ups also appeared on the Ruby on Rails homepage:

Rails is a full-stack, open-source web framework in Ruby for writing real-world applications with joy and less code than most frameworks spend doing XML sit-ups.

The common idiom with dynamic languages is to write configuration scripts or domain-specific languages in the language itself, instead of using XML. Compared to e.g. Java, XML is more agile and flexible, but that is not the case with dynamic languages such as Ruby or Python. XML.com has an interesting article about this issue.

.NET YAML parser by two of our students

I meant to blog about this for some time now

First some background information: second year computer science students at our university are supposed to do a big project to enhance their programming skills and ability to work in teams. The students can suggest a project themselves, or choose a predefined one from a list provided by the teaching staff.

Around January, I submitted a proposal to write a YAML parser for .NET. There were a couple of YAML parsers available, but none for .NET. A secondary goal was to release the final product under an open source license.

Jonathan Slenders and Christophe Lambrechts chose to do the project. Under the guidance of Tom Van Laerhoven, they produced a working YAML parser, and released it under the LGPL. It was mentioned on the YAML homepage in June. Since then they have received quite some mails from people interested in using their library.

The project will soon be placed on SourceForge. Until then, more information (including a description of the parser’s algorithm and documentation) can be found at http://lumumba.uhasselt.be/~christophe/YAML/.

The code is available through CVS.


Edit: the project is now available on Sourceforge.