Another weekend project idea is to investigate the implementation of an ASP.NET Membership Provider that supports LID/OpenID/Yadis identities. There’s an existing OpenID implementation for .NET, implemented in Boo, but you have to wire it up to your app yourself. A membership provider would be more drop-in, assuming the lightweight URL-based identity idioms can be shoe-horned into the fairly narrow membership provider API.

Recently I’ve tried to teach the Iraqi developers about the ASP.NET GridView, and how easy it makes displaying and editing multiple records. Unfortunately, we’ve had a helluva time making it work with MySQL.

First, we were using the ODBC.Net ADO.NET provider, and the 3.52 MySQL ODBC driver. This works fine, except the MySQL ODBC driver doesn’t support Unicode, a minor detail which means Arabic script is turned into garbage en route to the database! Supposedly, Unicode support is coming in the next version of the driver, discontinuously numbered ‘5.0’, which has been in development for over 1.5 years and is still in alpha; I was unable to get it to even install on my laptop without cryptic errors about missing files.

Today one of my Iraqi devs, E, was trying to display some search results from a MySQL database in an ASP.NET GridView control. He simply set the DataSource property to the DataReader attached to the results, and called DataBind() on the grid control.

All was well, except the dates; they displayed in the short date/time format, even though the times are not used in this application (and thus were all 12AM). I showed him the beauty of the DataFormatString on the BoundField which displayed the date, but to my surprise, setting it to {0:d} didn’t change the output at all.

I scratched my head for a while, then came across MSDN Labs Bug ID FDBK35199, which describes the logic behind this intentional behavior. The reasoning? To prevent script injection attacks, the DataFormatString property is applied AFTER the value is HTML encoded, so it’s no longer a DateTime by the time it is formatted.

Every year or so I find myself needing/wanting HTTP compression in a .NET app. This time around, I have an ASP.NET WebMethod which is passed a big glob of text by clients, and returns another big glob of text. I therefore want to compress the SOAP request and response. As it turns out, this is a Hard Problem. First, ASP.NET doesn't provide any HTTP compression built-in. IIS 6 will compress HTTP responses, or you can build an HTTP module in ASP.NET. In ASP.NET 2.0 this is made easier by official, MS-provided compression classes. Second, the .NET 1.1 @WebClient@ doesn't support HTTP compression _at all_. Period. The .NET 2.0 version supports decompressing compressed responses, but doesn't compress its own requests.