• Home
• About
• Contact

Subscribe

Tired of Spam?

Upcoming Book

Ads

Troubleshooting BlogML - .NET Library

So far I've written two posts about troubleshooting BlogML:

• Introduction
• Schema

In this post I want to talk about BlogML .NET library.  This library isn't a part of BlogML specification but we have created it from the early version to simplify the process of working with BlogML specification in .NET applications.

But what this library does for you?  This .NET library (which is written with C# in .NET 2.0 for BlogML 2.0) helps you to serialize your blog content into BlogML content (exporting process) or deserialize a BlogML file to appropriate .NET objects (importing process).  Classes in this library represent appropriate elements and properties represent attributes in BlogML schema.  In other words, all features that are supported by BlogML specification are implemented in this library and you can use them.  In my opinion this library is a good sample for working with XML in .NET.

When writing this library, we supposed that you have a well-formed XML file that is valid against BlogML schema so before using this library you need to make sure about this.  I can say that this library is now a part of all BlogML migrations even if users are migrating from or to a PHP blogging tool.  So far we've had usages of BlogML that had a .NET blogging tool on one side!

Therefore this library plays a very important role in the BlogML world.  Existence of a bug or exception in this library can be very critical and stop users from using BlogML.  Fortunately we haven't faced with any major problem with this library to now.  There are a few minor exceptions that we're going to handle in the next version but they don't stop anyone from using BlogML.

But let me talk about a few common problems that can occur for users.  One problem is the timeout error of export or import operations.  In both cases for large BlogML files (blogs with many posts) .NET runtime may return a timeout operation and stop the process.  This seems normal for this size of data and solution should be implemented in converter tools by increasing the timeout for operations.  Though this can be handled easily.  I can recommend you to perform export or import operations with good resources because for large BlogML files .NET may stop the process some time at the middle.

The other problem may be ASP.NET 2.0 medium trust level.  I personally haven't seen any reported problem about this and after checking the code, couldn't find any code security problem to cause errors under medium trust.  However, if you faced with any code security error, try to check this first.

The last problem that Jon Galloway reported to me last week is the usage of CDATA sections in your blog posts.  If you've already used CDATA sections in your post bodies, you may get an error when trying to export your blog posts to BlogML because by default we embed all blog post bodies inside CDATA sections.  Thank to Jon Galloway, now this is a known issue and has been filed to be fixed in next version.

I can't remember any other problem with .NET library at the moment.  Thankfully this library has designed in a very good way and doesn't have major issues.  For next version we even decided to unit test everything in this library in order to catch unexpected exceptions.  Right now I've reached to 48.04% of code coverage and surely improve it before final release of next version.  This library is a very abstract component and we had to spend much time to make sure it works fine for everyone.

The other thing that I'm checking for the next version is the validity of our library against framework design guidelines and so far haven't faced with major problems.

We hope that we can see similar libraries for other technologies in the near future to spread the BlogML and move forward to make it a better universal format.

6 Comments : 09.21.07

Feedbacks

#1
Granville Barnett
09.21.2007 @ 1:13 PM

Keyvan, give TDD a go within whatever process you use to push your code cov up - 48% is really very low. I know from past experience before my TDD days how hard it is to push code cov up, especially as your tests uncover bugs as you go along - some easy to fix, others hard. The best thing I've found is to employ TDD in your process and you should get high code cov. Takes more time but the rewards are obvious - software that behaves the way you expect, for your given scenarios.

#2
Keyvan Nayyeri
09.21.2007 @ 5:59 PM

Granville, You're right. But keep in mind that BlogML project was started before I join the team without a Test-Driven approach in the early months of 2005. To be honest, at that time Test-Driven approaches weren't very common. Yes, unit testing a code that is already written and has reached to a stable point is really a pain and I've experienced this in BlogML but there is no other choice for me. I have to unit test everything to make sure that underlying layers are working fine before testing upper levels of code. I usually use TDD for my projects from the beginning to make sure about the quality and stability. Something that I've experienced personally is if you use TDD from the beginning, achieving a high code coverage is absolutely easier than achieving it for currently written codes. One obvious reason is TDD prevents from extra problems so you build something that can be trusted in upper levels but without TDD you need to go back and forth to tune your code! Thank you for your comment :-)

#3
Granville Barnett
09.22.2007 @ 10:03 AM

I didn't know you had joined someway into the project. Glad to hear that you do use TDD though :-)

#4
Keyvan Nayyeri
09.28.2007 @ 6:14 PM

After writing an introduction to troubleshooting BlogML as well as two posts about BlogML schema and

#5
Keyvan Nayyeri
10.09.2007 @ 6:39 PM

As the last post of this series, I want to write shortly about BlogML issues related to import tools

#6
News
10.23.2007 @ 7:20 AM

My third post about troubleshooting BlogML is now published and discusses about BlogML .NET library

Leave a Comment