If you are not familiar with it, Babylon is an OCR / Dictionary program that can be a god send for trying to find the right word. I have bought the last two versions, but I don't think that I am going to give that compnay my money evey again.

The story is quite simple, I repaved my machine (when I installed Vista), and I wanted to install Babylon again. I couldn't find my key, so I pinged Babylon with a request that they will send it to me again. This is something that I have done before with a number of companies, and I never had any issue with them.

Babylon's response to my request was:

Over the years enormous amounts of Data accumulated in our systems.
This Data Base is constantly being maintained by a professional IT team, managing a vast hardware and software system.
Naturally, maintaining the Data Base systems does not come free of charge.
Therefore, restoring your license and setup file will cost a one-time fee of 7 USD.

As someone that deals with IT, I understand the enormous amounts of data that they have, but I find it hard to understand what is the big cost of running a SELECT on the system. And why something that should be built into the system should be so cumbersome. I can understand that this attidute means that they have low return calls, which may be nice for the support department, but very bad from the sales departments.

What is worse, when I (repeatedly) replied to the response above, I got no answer. So, for about two weeks, Babylon has been treating me in a way that is not appropriate if they intend to have me come back to them, and they decide to ignore repeated emails from me in this subject. I was a paying customer, but I do not believe that I would have any further dealings with them.

By the way, I have restored the license info from backup, to foretell those who would say that this is what I should have done in the first place. I am not arguing that, I am arguing that when I had a problem, Babylon treated me in a way that I find offensive, and then proceeded to ignore me.

As long as I am talking about reducing pain, here is a sample from a very secret project that I am woring on. I have a lot of parameters for the build script, and it got to be a PITA to try to manage them manually. There are several kinds of builds that I can do here, test, production, DB rebuilds, deploy, etc.

This quick (and very dirty) solution took about an hour of coding to build properly, and I just added some minor details after the intial build, enough to make it even more useful.

It is a build parameters UI for MSBuild, which basically display all the PropertyGroup elements, and apply simple heuristics for trying to figure out what the values are. For instnace, it can discover boolean values (and display check boxes), and clicking on the "..." buttons will display an Open File, Browse Folder, or Connection String dialogs, as appropriate.

As I said, it took about an hour (I wanted to leave it to my team-mates when I was at DevTeach), and it paid back in time, effort and sheer pleasure many times since. 

If you are a developr and you have some pain points, fix them, it will be well worth it.

(Yes, Roy, I know that Final Builder has a prettier interface :-) )

I posted before that adding the ability to copy files after a build was not as straight forward as it should, mainly because VS.Net decides to take active part in this and resolve the paths manually.

Here is how I ended up solving the issue:

This force runtime evaluation, and thus saving it from VS.Net clutches. I got the script from Doug, who uses it to copy files that are created on the fly.

Well, my Exception Dialog is completed.

In essence, it's purpose is to allows you to show exceptions to the user in a less intimidating way, while preserving the technical details that you may need.

How to use:

Ayende.Utilities.Error.ExceptionHandler.InitExceptionHandling(false, "your@email.com", "from@his-email.com", "Debug info: WinXP, 128MB, SP1, .NET 1.1.?, etc", "your.smtp-server.com", "Exception details");
Ayende.Utilities.Error.ExceptionHandler.HandleException(ex);

(There is some documentation in the file that explains everything, so I won't go over the boring details here.)
The above line of code will handle all unhandled exceptions, it will show a nice dialog to the user, with an option to send you the exception's info.
If for some reason it's impossible to send mail (not connected to network, for example), the user is prompt to save to file, so he can sent it to you by some other means (print & fax it, perhaps?)

As for normal use, just do this:

try
{
    //... some code that might throw exception
}
catch(MyException ex)
{
    Ayende.Utilities.Error.ExceptionHandler.HandleException(ex);
}

Here is how it looks:

Simple dialog && Advance dialog

How do you choose which will be shown?

HandleException() checks in the application configuration file for ShowDetailedExceptionDialog, if it equal to "True" (case sensitive, mind you), then the detailed exception dialog is shown, otherwise, the simple exception dialog is shown.

But there is a trick, press Backspace in the simple dialog, and it will show you the detailed dialog. Neat, isn't it :-S

The bits are here (removed link because it's old and very simple thing, and I need the space in the server)

Here it is, guys. My configuration manager.
I really likes this syntax:

string ConStr = ConfigurationSettings.AppSettings["ConnectionString"];

But this is read-only application-wide settings, it doesn't help you if you need to update the values, or want to use both application wide and user specific settings.
For this, I designed my own configuration manager, usage is really simple:

string ConStr = Configuration.AppSettings["ConnectionString"];

So far, exactly like you would've done normally, the real power is in the following statements:

if(Configuration.CanSetAppSettings)
   Configuration.AppSettings["ConnectionString"] = ConStr;
string Title = Configuration.UserSettings["Title"];
Configuration.UserSettings["HomePage"] = HomePageUri.ToString();

You can set the application settings, and you get user specific settings also settable.
Considering that as a normal user you might not be able to make machine-wide changes, you also get the CanSetAppSettings property, that tells you whatever you are allowed to do so.

The settings are preserved as XML files in the following directories:
Application settings:
 %CommonApplicationData%\<you application name\<major version>.<minor version>\<your application name>.config

User settings:
 %ApplicationData%\<you application name\<major version>.<minor version>\<your application name>.config

You can also get the file names programmatically using the UserFile and the AppFile properties.

You can iterate over the settings using the following syntax:

foreach(string key in Configuration.UserSettings)
   Console.WriteLine(Configuration.UserSettings[key]);

There is a tiny optamization for when you set a lot of settings in one go, to avoid saving them one by one, the actual saving is done tenth of second after the last setting, or at application shut-down.

Curently the only limitation is that it can handle strings only (similar to the FCL's ConfigurationSettings). If there will be demand, I will add the ability to serialize objects directly from the Configuration class.

Get it here.

Enjoy.

I'm planning on developing a set of utilities that I would use as building blocks for other applications. The main reason that I first and foremost a developer, I get itchy restless unless I code something.
The other reason is that I simply don't have the time to take on a lengthy project, but small & useful things are just right.
Currently I've a configuration manager that does user & app settings, like Whidbey has, and an exception UI Dialog which I still need to polish a little bit.

I'll show the configuration manager after I finish adding some finishing touches. The exception dialog will take some time, because I want to make it into a real working component, and not just some toy.