In the Photo Album Handler, one of our goals is to have everything in a single file for easy deployment (we still need an additional separate dll in version 2.1 but we're getting there). I also wanted the handler to be able to act like a Control so that it can be integrated in an existing site. Even when used in control mode, the handler part is still necessary to serve the thumbnail and preview versions of the images. We also want to enable the handler just by dropping it into the image directory without having to modify or create a web.config file, which forces us to use a .ashx file.
Last night, I uploaded the source code and release package for version 2.0 of the photo handler. I'll post more about the details of this new version in the next few days, but I can tell you that most of it has been rewritten, and it can now be used as a standalone application or as a control. What's more, the control is fully templatable, so if you don't like the default rendering, you can take it over and create your own. I've included a template example that reproduces the default rendering, which should give a good starting point.
Download the handler from here:
UPDATE: the handler is now hosted on Codeplex.
Well, if you have not pre-ordered six months ago and weren't ready to spend a good part of yesterday and last night freezing in front of Best Buy, your chances of scoring an Xbox 360 were near zero. So if you're like me, you just made fun of the guys waiting during this wet and cold night and just resigned to go home and wait for the next shipments.
Here's a misconception I see a lot on the forums lately. There is this idea that controls on a master page should always keep their state across content pages that use it.
When you navigate away from a page (i.e. when you click a link), you go to another page, with another instance of the controls on it, so of course the new controls on the new page have no way of knowing about the state of the controls on the other page.
Having a master page does *not* mean that all the controls on the master page have a unique instance that would be shared by all pages that use this master page. The master page is nothing more than a template, it's not any kind of singleton.
So the only way you can maintain the state across different pages (whether you use a master or not) is by storing it in Session and using that information when a new page is loaded. This can have severe performance drawbacks as you store state for each user but is more or less what WebParts do with their personalization data...
Another approach is to consider that if you need to maintain state across all those pages, maybe they are the same and you need to move from a many-page model to a single-page model.
Please note that the navigation controls (a.k.a. Menu, TreeView, SiteMapPath) will automatically select the current node in the site map according to the URL you're on, giving a minimum version of this application-level state management some were expecting from master pages.
If you want to check out what a real-world complex Atlas application would look like, Nikhil put together an amazing Atlas app around Virtual Earth and a few other web services such as Flickr and Amazon.
After years of hard work, version 2.0 of the .NET framework was launched this morning. This is a major event and something I think we're all proud of. We also launched Visual Studio 2005 (including Visual Web Developer Express), Sql Server 2005 (check out the free Express version) and BizTalk 2006.