In my opinion, there are a couple of things that combine in the current .NET Framework to form a void (wait, can two things combine to form a void)? Those two things are the strong preference for .config files over registry storage (a preference I agree with), and the lack of API support for writing config files.

The ConfigurationSettings class is great for reading your app.config or web.config file... but that file is specific to an application and not to a user. So while it's useful for storing things that are typically app-wide (database connection details, logging levels, etc), it's pretty much useless for storing user preferences. These usually include things like remembering a user's window size/positions, preferred file locations, or other user-specific settings.

There are lots of articles and samples online that suggest options for getting around these limitations. My opinion is that most of them fall just short of being complete solutions, though, and the reasons tend to be along these lines:

They don't allow for strongly-typed access to the preferences. To be really useful, reading and writing preferences should be idiot-level simple for the developer. If the dev has to write several lines of code to cast preference values to/from a string for storage, they're gonna skip it. The result is an app that's less flexible for the user than it could be. Another benefit of strongly typing the preferences API is that Intellisense helps the dev access the settings without having to remember key names.

They use INI files or the registry. Since the release of .NET 1.0, MS has steered developers away from using the registry. The registry is generally recognized to be a system that's prone to corruption and using this approach makes XCopy deployment a real pain. INI files are a fairly simple way to go, but they don't allow for a nested hierarchy and you end up dealing with a lot of parsing code. You also can't easily define metadata about each setting. .NET gives us a fairly rich set of APIs for XML, so why not use them?

They provide write-access to app.config. There are some articles that provide a wrapper for the app.config so that the developer can read and write to the file. There are a couple of problems with this -- first is that it's an app-wide file so all the user profiles on a shared machine will have the same settings. Second, app.config is in the application's startup directory, which is usually under \Program Files\. Standard user accounts under Windows don't have the ability to modify program files, so this option only works for Admin or Power User accounts. A better solution is to store preference files under a user's profile (\Document and Settings\[user]\Application Data\) -- even better is IsolatedStorage.

They use lots of files. Many articles and samples use XML serialization as a way to read/write preferences. It works well, but the suggestion is often to have a base Settings class and then many component-specific subclasses. Each component manages its own settings class, reading and writing as needed and then calling inherited members to serialize and deserialize the object. Maybe this isn't much of a problem, but for some reason it seems less elegant to me. The apps I work on tend to be large, modular Winforms apps -- lots of individual components, in which case I'd end up with a lots of files on the user's machine. Also in this scenario, components actually have to be aware of two types of settings -- their own settings and the app-wide settings that the user specifies. It gets worse if you have components that want to share some types of settings.

So do I have a solution for all this? Not yet. But I am reading as many articles and samples as I can find, making lots of notes, and trying to form a clear picture of what I think would be the "mother of all settings APIs". Admittedly, this would be with a bias toward Winforms apps. So far, there are two recent articles that are along the lines of what I'm thinking. These are Building a Better Configuration Settings Class (by Rick Strahl) and Manage Users Settings in Your .NET App with Custom Preferences API (Ray Djajadinata in July's MSDN Mag). Both of them offer good, complete coverage of the issues associated with a settings API.

At work last year, I built a fairly basic XML-based API that stores user preferences but it does suffer from a couple of the problems above -- most notable is that it's not strongly-typed. So... my current plan is to spend some off-hours going through the two articles above, continue to make note of the various ideas that are brewing, and then coming up with a new design that incorporates the pieces and parts that I think are important.

So with all that... am I missing any other key needs from a preferences API?

The Iraqi men's soccer team is playing Costa Rica today, after serving a big upset to Portugal last week. The current FIFA rankings have Iraq ranked 40th in the world, with Portugal at 12th.

Since the US men didn't qualify for the Olympics, I'm hoping the Iraqi team can make a solid run for a medal. These guys have dealth with torture, imprisonment, infrequent training, having to go to another country for "home" games, and being airlifted by the military out of their country. Given all that, and the uncertainty of things in their country, I'm really hoping these guys can make a run at a medal.

And to the players themselves... if you guys could find a way to abuse the Mexican team, that'd be much appreciated!

... that your team's coach is sure to get fired, they come from nowhere with a big win. The fact is, the team's lack of offensive production should mean they don't get into the playoffs. But under the MLS system this year, 4 out of 5 teams in each conference are in -- so as long as one team in the west sucks slightly more than the Rapids, they're in.

Please, Stan, do something.

Last week's .NET Rocks show with Jeff Richter was a great one. I always find it interesting to hear about the types of things that went (and are still going) into the design/implementation of the CLR. During the show, Jeff mentioned a couple of tips for helping the garbage collector be more efficient.

Keep object lifetimes as short as possible. I think this is essentially the same advice that's usually given for dealing with unmanaged resources (file streams, database connections, etc) -- get it late, release it early. It also tells me that I need to do some more reading up on WHY this is the case in the GC. My assumption is that it has to do with objects getting promoted through various levels of the GC and how often it runs through to free up memory. Definitely need to get a good book on the CLR guts. Suggestions?

Keep the call stack as short as possible. Again, I'm not sure why this is and plan to read up on it in more detail. But it does seem at odds with the common design/implementation goals of loose coupling and short methods. Usually, you want lots of small, cohesive objects that work together to form a larger component. Within those objects, you want relatively short methods that can use one another to perform an operation (do one thing, do it well, and do only that). The side effect of that approach is that the call stack gets fairly deep in short order. It may be that 95% of me experience in .NET  has been in the Winforms world -- wherein applications typically (and as was mentioned on the show) are going to have deeper call stacks than ASP.NET applications.

Anyway, interesting stuff... now off to find some good under-the-hood GC resources.

The more of his "Business of Software" articles I read, the clearer it is that Eric Sink just "gets it". I've read the BoS series on MSDN from the start, as well as his various weblog posts, and it's clear that he's spent a lot of time pondering what makes development really work. I also like that his advice obviously comes from someone who's been "in the trenches", understands real-world commercial development, and lives it each day. The series on the "22 Immutable Laws of Marketing" is a great example of his ability to break down software-business issues for the pocket-protector crowd.

This latest MSDN article is a good summary of things to look for when hiring developers into your team. What I really like is how he refers to "shrinkwrap qualities" -- those qualities that differentiate a good programmer from a good commercial-product developer.

My own experience is that there are lots of developers who pay lip service to OO design, architectural consistency, reuse, current documentation of all kinds, and so on -- but not all developers maintain that discipline day-in and day-out. And an even smaller percentage of those have the "shrinkwrap qualities" -- the ever-present understanding that what they're writing will eventually be in the hands of a paying customer. And while a well-designed, elegantly implemented software product is important (especially for the on-going maintenance and evolution of the product/product line), the end-user just wants an application that helps them get their job done and make their life easier.

Go forth and subscribe.

So I've had a seller's account on Amazon.com for years. Michelle and I often put up books we're done with or CDs we no longer want. You get an email when someone bought something from you (via the "Used & New" links on each product page) and then you have a couple of days to get it in the mail. Sometimes, after we've done some spring cleaning, that seller account can get up to a few hundred dollars.

Every 4-6 weeks or so, they transfer it to your bank account and send you a nice little summary of the transactions. Then you've got some side money with which to get more books, CDs, or movies... right? So where should you go to spend that money?

Well, what they DON'T offer is an option to just credit your regular Amazon.com account with the money in your seller's account. I don't get that... all they need is to provide a "Convert this balance to an Amazon.com Gift Certificate" option and they'd often get that money right back. Doing that leads to potentially three transactions that make money for Amazon -- My initial purchase of an item, their fee for me selling that item on their site later, and then another purchase using the proceeds from that sale.

I've emailed them about this before (have fun finding an email address on their site), but just got a boilerplate "thanks for your suggestion" response... so, what am I missing?

Andy Hunt and Dave Thomas, authors of The Pragmatic Programmer, did an interview with Artima last year and somehow I missed it until this afternoon. Great stuff here, but the part I enjoyed most was right up front when they talk about craftsmanship and how easy it is to fall into a trap of "I work on this piece and only this piece" on large projects. They refer to a quarry worker's creed -- We who cut mere stones must always be envisioning cathedrals.

The idea, of course, is that even those who work on small pieces of a much larger puzzle have to have the big picture in mind. Without that, the result is a finished project that lacks an overall, complete vision. Ok, so your part of the application is the database design, or the exception management, or the communications layer -- all are parts of a larger work that couldn't be built by any one person. Work on the stones but think of the cathedral. Take pride in your gargoyle.

The interview is well worth a read.

On that last post, I started to think about the similarities between my approach to code samples/mini-projects and my approach to organizing favorites/bookmarks. I'm pretty religious about "collecting" bookmarks for cool things I come across. With .NET articles, in particular, I've got about 15 different sub-folders under which I store bookmarks. Those sub-folders are for things like CLR, Exception Mgmt, WinForms, XML, SQL Server, Threading, Unit Testing, and so on.

I've got a pretty good collection of many different articles, from MSDN articles, blog articles, and other sources... the thing is that I'm really bad about going back and referencing them. Instead, when I'm on a project and need some info about a topic, I again go to Google.

Is storing all those favorites in Firefox a waste of time?

I really need to figure out a good way to organize code samples and little "test" projects. On my data drive, I have a folder called \download where Firefox puts all my downloads. Over time, that folder grows pretty large and I have no idea what some of the .ZIP files in there are. Often, I'm downloading code samples and utilities to look at but I need a good way to organize the stuff I want to keep.

I've started setting up a "Code Samples" directory structure, with sub-dirs for "WinForms", "WebServices", "XML", CompactFx", etc... but I'm not sure if that's going to be useful.

And a big part of me thinks I should just delete all but own little "test" projects... for all the little downloaded samples, there's always Google.

I just came across the blog of Alan Cameron Wills and had to subscribe in my feed reader. His first post, back in April, covers a development topic that is near and dear to me -- de-coupling components so that the parts of an application can be viewed independently. If you've done it well, adding/changing components to the overall system is trivial.

In the past, I've used the phrase "build a platform" to describe the approach, but the idea is the same -- rather than try to eat an elephant all at once (tackle a big project), take it in smaller bites (break the big project into small projects). View the app as a platform on which you can build components and capabilities.

Alan focuses his blog topic on the independence of those smaller projects (and says it all with far more clarity than I could). When you view a big project as a set of independent, smaller projects, it's easier to add other small projects (new components) later. If you go in with that thinking up front, your architecture is far more "pluggable" than if you view it as one big application and just start tackling it "a form/function/feature" at a time.

Good reading.

So I started using Mozilla Firefox about a month ago and I think it's official now -- it's my primary browser. It's got so many cool things that IE doesn't have (at least not yet). Things like tabbed browsing, quick searches for links in a page, a much nicer bookmarks/favorites manager, and built-in popup blocking.

The tabbed browsing thing alone is worth the switch, given that I very rarely have only one browser instance open at a time. More often, it's a handful of different articles, google search results, or news stories. I also like that you can save an entire set of tabs as one bookmark and return to them all via that single bookmark.

Another very cool feature is the ability to block images based on the domain in the IMG "src" element. I never see images now that come from the common banner ad servers. 

And the extensions/plugins being built are amazing. I use the GoogleBar (essentially the Google toolbar), a Flash blocker (it replaces Flash with a small logo that you can click if you want to view it), and a bunch of web development and related extensions.

Oh yea, it's also free.

So are there things I miss from IE? Sure... there are still a number of sites that don't work well in Firefox. IE's by far the most popular browser, so some designers don't bother to test their sites in other browsers. When I run across those pages, I use a Firefox extension that puts "View this page in IE" on my right-click menu.