Wednesday, February 21, 2007

My 60-second RSS primer

If you're already reading this and other technical blogs, there's a good chance that you're already familiar with RSS feeds. I wrote this 60-second primer to explain RSS for a co-worker today, and I thought I'd share it here as well for any other RSS beginners out there. Everyone was a beginner once!

RSS stands for Really Simple Syndication. It's a way for you to "subscribe" to frequently-updated web sites such as blogs, and be notified any time there is new content available on each site. Further, you can use an "RSS Reader" application to manage all of your subscriptions, and to read all of the new content from within the reader application.

Why bother with using an RSS reader instead of just directly visiting the website of each individual blog that you like to read? Here are two pretty good reasons:

(1) You don't have to spend time visiting a site only to find that it hasn't been updated since your last visit.

(2) It's faster to skim/read all of the new content from the sites that have been updated from a single centralized location, instead of having to visit them all individually.

How do you know if a site provides an RSS feed of its content? Such sites will generally display a small orange RSS icon somewhere on the page: RSS In Firefox, the RSS icon be displayed at the right end of the browser's address bar when you're at a site that provides an RSS feed. You can generally copy-and-paste the site URL into your RSS reader to subscribe to the site's RSS feed. In Firefox 2 you can just click on the orange icon in the address bar, and it will automatically handle the subscription for you, if you already have an RSS reader program set up.

Here are a couple of links for you to get started with. The RSS reader I use is a free web-based application called Bloglines, located at One of my favorite blogs to read is Jeff Atwood's "Coding Horror" technology issues blog at

Thursday, February 15, 2007

Windows Forms in IE don't load properly in ASP.NET AJAX 1.0

I'm currently running into a problem where Windows Forms .NET controls embedded in a web page, when included in an ASP.NET AJAX UpdatePanel, fail to load properly after the UpdatePanel is updated. An "x" icon is displayed where the control should be.

For a simple UserControl that would normally appear like this:

This is displayed instead after the AJAX update:

Unfortunately, I haven't been able to figure out the root cause of this issue yet. I took a look at the post-update HTML (using a trick from Rumen Stankov -- thanks Rumen!) generated by ASP.NET AJAX, and the HTML looks to be ok.

The problem can be reproduced using a simple .aspx page:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "">
<html xmlns="">
<head runat="server">
 <title>ASP.NET AJAX and Windows Forms</title>
 <form id="form1" runat="server">
   <asp:ScriptManager ID="ScriptManager1" runat="server" />
   <asp:UpdatePanel ID="_gaugesUpdatePanel" UpdateMode="Conditional" runat="server" >
       <asp:AsyncPostBackTrigger ControlID="_updateButton" />
       <object id="TestControl" name="TestControl"
         height="100" width="200">
   <asp:Button ID="_updateButton" Text="Update" runat="server" />

When this page initially loads, the Windows Forms control displays correctly. After the "Update" button is clicked (triggering the UpdatePanel to be updated), the control fails to load and the "x" icon is displayed.

For this sample, the "Default.aspx.cs" codebehind page is just the default empty page generated by Visual Studio, and the TestControl.dll is a .Net library with a single simple UserControl, "SimpleUserControl", which just displays itself with a gray background and the "SimpleUserControl" label (as shown above).

The issue is reproducible on both Internet Explorer 6 and Internet Explorer 7.

When the issue occurs, I don't see any warnings or errors recorded in the Fusion Bind log, the web server's IIS log, or the client's Application Event log. (IE is generally pretty bad about providing any detailed error information when something goes wrong with loading a .Net control embedded in a web page, but there is usually at least some information recorded in one or more of these logs.)

My dev group is opening an incident with Microsoft Support for this issue. If we end up getting a workaround from them, or if I am able to come up with a workaround on my own, I'll update this post with the new information.

Update 3/6/2007: I've now discussed this issue over email and phone with Adam S., a member of Microsoft's ASP.NET developer support team.

Adam put together a simplified repro case for this issue with a simple .html (rather than .aspx) page showing that the problem isn't directly with the ASP.NET AJAX controls, but rather with Internet Explorer's implementation of displaying a Windows Forms .Net control that has been placed on a page by setting the innerHTML property of a <div> element with HTML that includes the control's <object> tag. (ASP.NET AJAX leverages the innerHTML property to do its content refresh of UpdatePanel controls, which is why I saw the problem happening with ASP.NET AJAX.)

Adam let me know that this IE bug with setting an element's innerHTML property with HTML that includes an <object> tag is tentatively scheduled to be fixed in Internet Explorer 8.

Of course, while a future IE8 fix for this issue would be nice, it isn't especially helpful to me right now, since I need to have my web application working on IE6 and IE7! For now, I'm going to rewrite my web app to use standard full-page postbacks to update the set of Windows Forms controls displayed on a page, instead of being able to update just a particular portion of the page using AJAX.