Just spent way too much time fixing VB code coloring on MSDN2

You may have already noticed this, but the current build of MSDN2 has a bug in the way it colors VB code snippets, as you can see here (scroll down, there are quite a few problems in the code snippet coloring, see how many you can spot!)… turns out the code wasn’t handling comments right, text in quotes, and it didn’t have a full list of the VB keywords (so MsgBox was not recognized, for example). I’ve fixed it all up now (I think) so that code will work its way through review and test then get added to some not-too-distant update of the site code… but for now, here is the revised output for those particular code samples.

Broken

' Imports statements must be at the top of a module.
Imports Microsoft.VisualBasic.CallType
Sub TestCallByName1()
    'Set a property.
    CallByName(TextBox1, "Text", CallType.Set, "New Text")

    'Retrieve the value of a property.
    MsgBox(CallByName(TextBox1, "Text", CallType.Get))

    'Call a method.
    CallByName(TextBox1, "Hide", CallType.Method)
End Sub
Public Sub TestCallByName2()
    Dim col As New Collection()

    'Store the string "Item One" in a collection by 
    'calling the Add method.
    CallByName(col, "Add", CallType.Method, "Item One")

    'Retrieve the first entry from the collection using the 
    'Item property and display it using MsgBox().
    MsgBox(CallByName(col, "Item", CallType.Get, 1))
End Sub

Fixed

' Imports statements must be at the top of a module.
Imports Microsoft.VisualBasic.CallType
Sub TestCallByName1()
    'Set a property.
    CallByName(TextBox1, "Text", CallType.Set, "New Text")

    'Retrieve the value of a property.
    MsgBox(CallByName(TextBox1, "Text", CallType.Get))

    'Call a method.
    CallByName(TextBox1, "Hide", CallType.Method)
End Sub
Public Sub TestCallByName2()
    Dim col As New Collection()

    'Store the string "Item One" in a collection by 
    'calling the Add method.
    CallByName(col, "Add", CallType.Method, "Item One")

    'Retrieve the first entry from the collection using the 
    'Item property and display it using MsgBox().
    MsgBox(CallByName(col, "Item", CallType.Get, 1))
End Sub

RSS feed authoring for those without blog software or an enjoyment of typing angle brackets

Blogs and blogging software seem to be everywhere these days, and RSS has been a top buzzword for quite some time, everyone and their dog wants to take advantage of this new trend and technology. The problem is, it isn’t a simple process to create and maintain a valid RSS file. If you aren’t willing to run a complete blogging system or if you aren’t capable of hand-editing XML, then you don’t have a lot of options. For most of the folks that will read this blog entry, you probably don’t have this problem, producing RSS 2.0 wouldn’t be much of an issue for a developer, but there are times when we want less technical folks to be able to author their own feeds without any assistance. At MSDN we started thinking about this very problem ourselves recently when we decided that, in addition to all the feeds that come out of our content systems, there was a need to create some small feeds that didn’t necessarily fit into our larger content systems. Handing off the task of feed creation to notepad or Front Page wasn’t an appealing thought and that path would probably result in a lot of xml editing errors and invalid feeds.

This problem happened to line up with a sample I had been thinking of though, so I wrote a quick app using VC# Express 2005 to try and help out; a Feed Writer that allows you to create new RSS 2.0 feeds, edit existing ones, and even import entries from one feed to another. I stuck to a tried and true UI structure, tree along the left side then entry fields on the right:

This app has been developed without the general user in mind, MSDN/TechNet were the targets and because of that there are some fields in this UI that are only relevant to the needs of those groups. For example, the list of attributes you can see on the lower-right is specific to the needs of MSDN and TechNet, who need to markup the feed entries with the appropriate choices. The “Type” and “HeadlineImage” fields are also specific to MSDN feeds, I’m planning to adapt it to work with ‘standard’ RSS 2.0 items and the category element to make it more general purpose, but for now I thought I’d show you the version I already have running.

In a rather backwards fashion, I’m going to finish up this as a sample and write the article, now that I’ve finished the actual practical version of the same system… but it will all work out in the end.

After some discussions with Sam Ruby and others on the FeedValidator mailing list, the MSDN RSS feed validates as is…

In an earlier post, I discussed the fact that the MSDN feeds were failing to validate due to a MIME type that included parameters (charset in this case, like ‘text/html ;charset=utf-8’), but I also posted a query about this issue into the listserv for FeedValidator.org. Sam mentioned it on his blog, and then went ahead and updated the validator to recognize a MIME type with parameter as valid.

In the meantime, I updated the MSDN generator to strip out the parameters :), but I still think they are technically valid so I’m glad the feed validates as it is today (with params) and as it will exist in the near future with the MIME types stripped down to just type/subtype.

A bug in my RSS generator, but is it really invalid?

The RSS generator for MSDN, creator of this feed, and many more … has a small problem. Way upstream, when various people inside the company enter information about an upcoming headline, they have the ability to specify a URL to a download. The intent was for this to be a URL to an actual downloadable file, so when I generate an RSS item from that headline entry, I take that URL and turn it into an enclosure entry in the RSS file.

<item>

<title>Read about Atlas - Ajax for ASP.NET</title>

<description>ASP.NET "Atlas" is a package of
new Web development technologies that integrates an extensive set of
client script libraries with the rich, server-based development
platform of ASP.NET 2.0. </description>

<link>http://msdn.microsoft.com/asp.net/future/</link>

<dc:creator>Microsoft Corporation</dc:creator>

<category domain="msdndomain:ContentType">Link</category>

<category domain="msdndomain:Audience">Developers</category>

<category domain="msdndomain:Hardware">CPU</category>

<category domain="msdndomain:Operating Systems">Windows</category>

<category domain="msdndomain:Subject">Web development</category>

<msdn:headlineImage />

<msdn:headlineIcon>http://msdn.microsoft.com/msdn-
online/shared/graphics/icons/offsite.gif</msdn:headlineIcon>

<msdn:contentType>Link</msdn:contentType>

<msdn:simpleDate>Sep 19</msdn:simpleDate>

<enclosure url="
http://go.microsoft.com/fwlink/?LinkId=52384"
length="17437"
type="text/html; charset=utf-8" />


<guid isPermaLink="false">Titan_2519</guid>

<pubDate>Mon, 19 Sep 2005 18:20:40 GMT</pubDate>

</item>

This generally works fine, I make a HEAD request with that URL which gives me back the MIME type and the Content Length, both of which are needed for the enclosure element in the RSS item. Sometimes though, people put in a URL to the download’s landing page, not the download itself. There are good reasons for this, as the download page often contains useful information and/or multiple localized versions of the download, but it was not what I expected. In this case, I put the enclosure in with the MIME type I get back from that URL, which ends up being ‘text/html’ and with a byte size that reflects the size of the landing page.

This wasn’t really what I wanted to happen, so I need to figure out a solution at my end, but what I noticed today and what has me a little puzzled is that at least two different validators (here and here) report these types of entries as validation errors. The error they specify is that text/html is not a valid MIME type…. but, according to the RFC(s) (see 4.1.2 of this RFC) and other sources, it most certainly is a valid type. So, is there a hidden rule in RSS that enclosures have to fall within some special subset of MIME types, or are both of these validators broken? Sure, in this case it wasn’t really what I wanted, but what if I really did have a text/html document for you to download?

VB Futures section up on MSDN…

Now, to me, VB 2005 is the “future”, and anything beyond that is really just coffee-break information to read briefly…. but I guess I wouldn’t be a very good Microsoft person if I didn’t start pushing the version-after-next version of our development tools before the next version has even shipped.

So, with that in mind, check out http://msdn.microsoft.com/vbasic/future/ which, despite my comments, is quite a good pile of info on post-Whidbey VB features and even includes a download to bring LINQ features in VB 2005. Hmm… ok, I guess with that download it seems a bit more ‘current’ to me … hmph…

Pulling from MSDN… the code…

(see this post for an introduction to this topic…)

I’ve wrapped my code up into a user control that you place anywhere on your page… it handles the load of data and then you can access its properties to output the html headers and body of the pulled content. I’ve just been using Output Caching on the host page, but if you decided to cache the body/headers that would certainly work as well…

Here is an example of using the control on a bare bones page…

<%@ Page Language="VB" Debug="true" %>
<%@ OutputCache Duration="360" VaryByParam="*" %>
<%@ Register TagPrefix="dm" TagName="Pull" Src="Pull.ascx" %>
<dm:Pull id=pagePull runat="server"
QueryParam="pullURL"
DefaultURL="http://msdn.microsoft.com"/>
<html>
<head>
<%=pagePull.PageHeaders%>
</head>
<body>
<%=pagePull.PageBody%>
</body>
</html>

This simple page and the ascx are bundled up into a .zip file available here