Robert McLaws: FunWithCoding.NET

XmlTextWriter + StringWriter = Headache

I've come to the conclusion that .NET doesn't really make coding easier (yet), because most Framework classes are incomplete, and use Inheritance as an excuse to leave them that way. Case in point: XmlTextWriter.

I'm changing GenX.NET's XML formatter to use the XmlTextWriter instead of building XML manually. It's a bit cleaner this way, and I can use formatting to overcome this really weird issue I've been having with the StringBuilder.ToString method putting in breaks every 1024 characters. More on that later. Anyways, so the XmlTextWriter constructor takes an instance of the StringWriter class, which is where the problems begin. The XmlTextWriter's constructor looks like this:

Sub New(StringBuilder)
Sub New(Filename, Encoding)
Sub New(System.IO.TextWriter)

The lameness begins. So you can't set the encoding of the XML document if you pass in the StringBuilder. Sucks to be me. So I whip open the Object Browser, navigate to the XmlTextWriter, and I get the following pearl of wisdom:

Public Sub New(ByVal w As System.IO.TextWriter)
Member of: System.Xml.XmlTextWriter

Summary:
Creates an instance of the XmlTextWriter class using the specified System.IO.TextWriter .

Parameters:
w: The TextWriter to write to. It is assumed that the TextWriter is already set to the correct encoding.

Well, this would be a fabulous assumption to make, save for one thing... The TextWriter's encoding property is READ ONLY. La-de-frickin-da. Time to add bloat to my codebase again.

So I do a GoogleSearch on “XmlTextWriter StringBuilder Encoding”, and I get Roy Osherove talking about the subject. The dude knows XML & .NET, so I'm thinking “Great”.... but no dice. The examples in the comments don't work. The 2nd sample freaks out IE because the IE XSLT parser can't hack it if there are spaces at the end of the file. For some reason, converting a MemoryStream's buffer to a string kicks out extra data at the end. This is very bad. 45 minutes wasted.

The 1st example does not exactly work, because it doesn't allow for a StringBuilder to be passed in. This one is simple enough to correct, I just hate adding unnecessary code to my object model. The solution looks like this:

StringWriterWithEncoding Class:

Imports System.IO
Imports System.Text

Friend Class StringWriterWithEncoding
    Inherits StringWriter

Private m_encoding As Encoding

Public Sub New(ByVal sb As StringBuilder, ByVal encoding As Encoding)
    MyBase.New(sb)
    m_encoding = encoding
End Sub

Public Overrides ReadOnly Property Encoding() As Encoding
    Get
        Return m_encoding
    End Get
End Property

End Class

Protected Friend Overridable Function DataReader(ByRef FromDataReader As SheetBuilder.FromDataReader) As String Implements IFormatProvider.DataReader

    Dim i As Integer
    Dim sb As New StringBuilder
    Dim writer As New XmlTextWriter(New StringWriterWithEncoding(sb, Encoding.UTF8))

    writer.Formatting = Formatting.Indented
    writer.WriteStartDocument()

    writer.WriteStartElement(“document“))
    writer.WriteElementString(dr.GetName(i), HtmlEncode(dr.GetValue(i).ToString))
    writer.WriteEndElement()

    writer.Flush()
    writer.Close()

    Return sb.ToString
End Function

There you have it. Now you can add whatever encoding you want, and the StringWriter will compensate accordingly. Notice also that the XmlTextWriter DOES NOT compensate for things like Ampersands (&) and so forth. I decided I'd take the burden off of the end user, and sacrifice a little performace by HtmlEncoding the output, rather than risk a document breaking and having to deal with a support issue.

Hopefully, MS will fix that stupid ReadOnly property and make it a two-way street, like they did with the SelectedValue property in the DropDownList. For now I'll have to use mine.

Is it just me...

StringBuilder Size Algorithm

When I posted about this before, someone noted that cycling through all the items would be a performance hit. Well, as you can see, I'm really only cycling thru the tables in the DataSet, and in the case of the DataReader, I'm only accessing a property that already exists.

For DataSets:

Dim FieldCount As Int32 = 0

'Algorithm for setting the minimum StringBuilder size initially, so that we do not have to continually re-allocate memory
'This should increase performance
For Each dt In dataset.Tables
     FieldCount += dt.Columns.Count * dt.Rows.Count
Next
sb.EnsureCapacity(FieldCount * 25)

For DataReaders:

Dim FieldCount As Int32 = 0

'Algorithm for setting the minimum StringBuilder size initially, so that we do not have to continually re-allocate memory
'This should increase performance
sb.EnsureCapacity(dr.FieldCount * 25)

This should be fairly adequate in most situations. You want to undershoot by less than half, because if you can do that, then it will only resize once, having reached it's maximum capacity a little more than halfway through. When the StringBuilder resizes, it doubles it size, so this logic only makes sense. You don't ever want it to resize more than once tho, otherwise you'll have way too much wasted memory.

Webservices + SSL = Good or Bad?

VSIP Corroboration

“Be sure to read the EULA” - John Tobler

Yes, definitely. There is a clause in there that says you are OBLIGATED to upgrade your code within 180 days of a new VS.NET release to be compliant with that release.

4. OBLIGATION TO UPGRADE ELIGIBLE PRODUCTS.

To the extent that You continue to distribute Eligible Product(s), You shall begin making available for licensing to End Users through Your normal channels of distribution new, updated versions of all such Eligible Products no later than one hundred eighty (180) days after the date that We commercially release each new version of Visual Studio .NET Technology. Such new, updated Eligible Products shall include a reasonable level of support for and integration with new features and functionality included in new versions of the Visual Studio .NET Technology. You further agree that You shall distribute updates or service pack releases for Your Eligible Products no later than one hundred eighty (180) days after the date that We commercially release an Upgrade for the Visual Studio .NET Technology. Each of Your update(s) and/or service pack release(s) shall include a reasonable level of support for new features, bug fixes and other incremental changes in Our Upgrades. Nothing contained in this Section shall prevent You from distributing old versions of Your Eligible Products to End Users that do not desire to upgrade to new releases of Your Eligible Products.

 For some people, like Frans, this may be a problem.

Also, note that the installation modifies your VS.NET installation to show VSIP status. I'm not sure what this does to distributed components, but I'm about to find out in a few hours, when I send the GenX.NET final build to our beta testers.

DAL Article Finally Out

My long-awaited article on Data Access Layer security is here! None of what I talk about is really new information, but it is put forth in a very unique way. Here's an excerpt:

For many developers, building applications is a lot like building a family. The Business tier is like the oldest child: mature and responsible, it knows how to handle everything, and is good at telling people what to do. The Presentation tier is like the youngest child. The baby of the family, this one is cute, flashy, and gets all the attention. The Data tier is often like the middle child: pivotal to the family unit but largely unnoticed, insecure, and left to fend for itself. In this article, I'm going to show you how to nurture your middle child, the Data tier, and give it the tools it needs to survive in harsh environments.

Whidbey Information

VS.NET Shortcuts

Having just registered for and been accepted to the Visual Studio Integration Program, I've been going through the included Help collection, and found some neat little tidbits. These actually have nothing to do with the VSIP SDK, but the SDK did lead me to some great docs in the regular VS.NET 2003 Help Collection.

Visual Studio.NET 2003 Shortcut Reference

Build Better Setup Routines

VS.NET Automation Object Model Diagram

Today, I am a sponge. I wish this stuff was in PDF format so it was easier to read/print out smaller sections. <shrugs>

"No-Brainer Compatibility" Explained

For several weeks now, I've been talking about various issues in regards to component versioning and Framework compatibility. A few months ago, I got so frustrated by the issues that were raised, that I said I was going to start a task force to solve the problem. This task force was informal and basically consisted of Paul Alexander (XHEO) and I (Interscape Technologies). Over the past 6 months, I have really enjoyed working with Paul, and I am constantly amazed at the work he achieves. Together, we've been able to make some headway in the industry as a whole, and we have several extremely exciting things coming up in the future.

The results of this work were detailed informally in my weblog, but will be published through Builder.com officially over the next 6 weeks. By the end of the week, I will have a single, final document available on my company website. For now, thought, I want to focus on the images I posted this morning, and the role they should play with your marketing.

This overall system that I've come up with, I'm dubbing the “No-Brainer Compatibility Initiative”. This is not meant to be derrogatory by any means. It really should be a no-brainer to the people that use the reusable code that we distribute/sell regarding how it works, and which version to use it to. All too often, developers assume that the end user/other developers that will be using thair code are just as smart as they are. All too often, this is not the case. Most .NET developers are either coding newbies or coding converts. Many come from the Java realm, and just as many come from ScriptKiddieLand. Most, myself included, wouldn't know good programming methods if they came up and bit them in the ass. I'm still learning about design patterns and so forth.

So the point is to make it blatantly obvious to anyone with an IQ above 20 which version goes with which Framework. It's not that hard. The first step is to use the Framework Compatibility Graphics (FCGs) I blogged about this morning. Roy Osherove asked me, “Where do I put these graphics... in my installer or some kind of splash screen?” My answer: “Yeah those, but first and foremost, on every product-related page of your website, your documentation, and any product related support website page.” You want to build as much awareness as humanly possible. You also want to put the graphic in an and make the link to go a page with the large version of the graphic, and explain in more detail exactly what it means. Paul and I may be coming up with standard text in the very near future, to help you guys out of you're having trouble.

The next parts of this initiative stem my previous posts here, here, and here, and are addressed in greated detail in my Builder.com column next month. Paul has already taken these steps with XHEO|Licensing 2.0, as shown in the following screenshot:

Is there any question from that dialog which version you should use in VS.NET 2003? I sure hope not. As a user of XHEO's products, there sure isn't for me.

Now, this is not necessarily the best way to do it. It is, however, the best anyone has come up with so far. Try it, experiment with it, and make it better. When you do, please be sure to let me know. This is why I talk about this stuff instead of keeping it to myself.

Congratulations ScottW

I was the first to say it last time, and I'll be the first to say it again. Congratulations Scott on the new version of the Weblogs. It looks extremely professional, and I love the new selection of skins. I can't wait to pimp mine out with .NET-related graphical goodness. The new admin site is extremely clean. Now, I'm just waiting for my stats.... ;)

Great Job! <applause>