June 2003 Blog Posts

Greg writes: "Hot out of the RAI lab...RSS feeds generated from Visual SourceSafe. Many development shops use some kind of email notification for source changes - and this is a perfect application of RSS."

Is this really "a perfect application of RSS"? I'm not sure - the HTTP polling troubles me but in some ways it's little different from POP3 polling for e-mail. I'm not saying this is right or wrong and certainly not getting at Greg specifically. I've seen this type of comment in other places dealing with other kinds of resources such as Windows event logs. Is RSS the best approach?

Funny you should ask. I remembered writing about just that on my weblog a while back. So, I fire up Google, type in "SAP .NET Scoble" and out came the answer.

Now you know why I link so many things here. If I ever need to find something, I'll just fire up Google and find it. [The Scobleizer Weblog]

This is largely why I set-up a weblog.

The startup time of VS.NET 2003 seems vastly improved over the initial release... [Shawn A. Van Ness]

Nice tip.

If you were confused about XML, this picture will help or make it worse. :)

But the cool thing is, the pictures are linked to the specs.

By way of Cedric Beust's weblog. [ CraigBlog]

Cool!

Everyone knows what the right answer is, but the problem is that half of them know that it is "fix it" and half of them know it is "don't fix it", and they all scream really loud. [Better Living Through Software]


The difficulties of maintaining an API for an externally managed spec.

Dr. GUI describes how to avoid potential deadlocks in multithreaded programs by not using the common, but wrong, idiom of locking a type object. [MSDN Just Published]

Scott Guthrie writes:

...if you have images only used by that user control, you can create a "images" directory that lives in the same directory as your usercontrol -- and then use relative paths to the images using asp.net server controls. For example:

<img src="image/foo.jpg" runat="server"/>

Or

<asp:image imageurl="image/foo.jpg" runat="server"/>

ASP.NET will then automatically fixup the path to the image to be based on the physical path of the user control. That way, regardless of what page the user control is used on (even if a different subhierarchy), you'll get the right path to the image. Internally we use the Page.ResolveUrl(path) method...

PowerToys for Visual Studio .NET 2003 are a collection of cool utilities and tools developed by Microsoft that enhance Visual Studio. This initial collection of PowerToys will allow you to fine-tune Visual Studio’s hidden registry settings, add comments and build help files, load files from the command line and create custom IDE window layouts. All of the PowerToys for Visual Studio .NET 2003 releases also include the source code for you to freely modify and distribute to your hearts content.

I've been working on an application that needs to handle the case where different users and/or different servers are located in different time zones. To accommodate this, I figured it would be best to ensure that all date/time values would be stored and manipulated in universal time (UTC).

For textual representations of date/time values, I've used the XML canonical format CCYY-MM-DDThh:mm:ssZ, for example 2002-04-20T23:59:07Z. Unfortunately, I had wrongly assumed that using DateTime.Parse() on such a string would return my UTC date.

The fact that DateTime.Parse() converted the value to local time was a bit of a surprise to begin with. The more I think about it, though, the more sense it makes. Consider these two strings: "2002-04-20T23:59:07Z" and "2002-04-20T23:59:07". The first is in UTC and the second is, well, we don't know - local time I suppose. And I guess that's the key - if the second is parsed and retains the given hour and we accept that it is in local time, it probably makes sense that the first is adjusted by the local time zone offset in order that we can make a comparison between them in a like for like manner. Just caught me off guard is all. A quick call to ToUniversalTime() and all is well again.