CallContext

ReSharper 4.0 has just hit beta! I have been using ReSharper for about a year now, and it is an awesome productivity boost. You can really concentrate on writing code, and let ReSharper take care of the little stuff, as well as some pretty major refactoring tools.

At the moment, I can get a special 60-day trial key for ReSharper if you email me and let me know you want it! I can't help but suggest you try and buy this software. If you can only have one addin for VS, then this is the one.

I can't believe the pain I've been through up to now, and I'm still not finished setting up the first iPod! I'm starting to think the no-name brand USB MP-3 player's are where it's at.

I honestly believe Apple's entire Windows testing of iTunes consists of installing the program on a clean Vista machine using an account with administrative rights. I have been through hell, and now they're insulting me by asking me to put my credit card details into my 9yo daughter's iTunes store account! There's no option for me not to do this! This is ridiculous.

Here's my angle, without hopefully giving up too much personal information as to see my children kidnapped by Apple...:

• I have two beautiful daughters, both too young to have credit cards/mobile phones/etc, but they both received iPod Nano's for their birthdays this year, like many their age I'm sure.
• I have been trying, completely unsuccessfully to install iTunes on the family computer in the main living area, but it just flat-out refuses to start. The install goes fine, but there's no love after that. Searching the internet, I find there's a few people having the same problem. I've tried every one of their suggested fixes, with no luck. So now I'm installing it on my older laptop. For some unknown reason, it installs fine on here, despite both machines running Vista.
• I, for some bizarre reason, want to protect my children while they're online so I run the parental controls. There's no effective way from within iTunes of working with the parental controls to allow access to the relevant parts of the Apple infrastructure. I did as much as I could through Internet Explorer by going to the Apple website etc, but I still couldn't get access to the latest iPod firmware update. Now the parental controls are off. Not happy, Jan.
• My girls also received iTunes gift cards. This is the reason for wanting to set up access to the iTunes store. However, there's no apparent way for creating an iTunes store account without entering credit card information! So I couldn't use the gift cards without giving Apple my credit card! Now the girls could potentially buy music whenever they want. We're going to have to check on them constantly when they're on the store now just to make sure. I'm not saying they'd wilfully purchase music on our credit card, but I bet there's no checks in place to prevent it from happening accidentally.

This is really an ordinary experience. For someone who's used to hearing people bang on about how rubbish the Windows user experience is, and how haphazardly their software seems to be thrown together, I'm completely stunned at what I've been through in the last few weeks just to get two MP-3 players hooked up and working with their own software!

Amazing. Should anyone from Apple stumble across this post, I'm more than willing to help sort this crap out, but we both know that's never going to happen...

This post has an awesome list of Visual Studio IDE enhancements! Just sticking it here for the BAS.

Bil Simser has written a great article on the day-to-day use of subversion. It explains everything from the initial set-up, through tagging, branching, and merging.

His example uses a branching pattern called "Feature Branching". Another name for feature branching (and one you might be more familiar with) is "Development Branching".

The idea is, any development work is done in a branch until such time as the work is considered complete and ready to merge back into the trunk. Release builds are done directly from the trunk.

The other major branching pattern is "Release Branching". In this scenario, all development work is done on the trunk. When the current development phase is considered complete, a build is done and tagged, then a branch is made. Any maintenance work is carried out in the branch and subsequent releases can be made from it.

The method used to introduce me to subversion was release branching. I believe it's the method used by Microsoft in operating system development.

I'm pretty comfortable with it, as it's how I've been working for a while now. I think it's the simplest form to work with, but you're putting a lot of faith in the people developing in parallel with you. If they screw up, the trunk is hosed.

Feature branching means a bit more overhead in your development workflow, but the benefit is the trunk is always good. Should someone hose the branch, the trunk can still be built.

If your build is always being broken, try feature branching. If you're a small team with good communication and a lot of trust, use release branching.

If you want an in-depth exploration of software configuration management (of which, revision control is one aspect), have a look at this site.

ma78gs2h.rar

It finally clicked with me this afternoon while watching Luca Bolognese demonstrate Linq to SQL to the EMEA crowd.

Linq to SQL (L2S from here on) is about the data. NHibernate is about the domain. At least as far as I understand.

In the demo, Luca at first creates what would appear to the naked eye to be a domain object, but it's really just a very decent wrapper class DTO style object. He then goes on to say if you were doing anything remotely serious with L2S you wouldn't work that way.

He then shows the "proper" way to do it, which is to take your database schema and drop it into the L2S classes designer. The designer wires everything up relation wise and you can even throw stored procedures in there. At the end of the day, however, you're just mimicking the database in code. This does not lend itself to the One True Way™.

I want my domain model to be completely ignorant of the database schema supporting it. The domain model should be free to do what it does best (model the domain, ahem), and the ORM should be left to do what it does best: map the domain model to the database using the rules you define.

How does L2S deal with inheritance? Composition? Polymorphism? There will be ways to deal with it, but it's not the intent of Linq. As Anders says, Linq is about stopping programmers being plumbers. I don't want to know the disgusting details of how the data gets from that box over there into objects in my code. I just want it to show up.

NHibernate removes the plumbing, but you still have to be aware of the database. It's still possible in NHibernate, as it will be in L2S, to write code that will bring the database server to it's knees. You need to be aware of this. You also need to be aware of the SQL that it will generate to try to fulfil your requests.

I'm still definitely in the NHibernate camp for serious work, but it's a tough call between ActiveRecord and L2S for me. It looks like a bit less work to set up L2S and get data back than with ActiveRecord.

Also, this doesn't mean you can't use Linq with NHibernate. Quite the opposite. Linq on it's own works wonders with NHibernate. There's some community support around Linq and NHibernate as well, with some code earmarked for the NHibernate libraries coming soon.

This is also not meant to be a L2S bash. Quite the opposite. I'm extremely impressed with what L2S does, and how it does it. I only wrote this post to clarify what I perceive as the differences between L2S and NHibernate.

Go and give it a whack.

Another thing I like about Vista: when apps die, they kind of fade to a paler, washed out whiter colour. Makes me think they're heading for the light...

These are things I see popping up a bit these days. I like the way they expose their intent through the "fluency" of the language of the statements.

For example, I've been used to writing asserts in my unit tests like so:

   1: Assert.AreEqual("This thing", result);

And I've just tried the fluent interface exposed by NUnit along with one of the provided methods of the string class:

   1: Assert.That(result.Equals("This thing"));

It achieves exactly the same result as the first example, but it reads a lot cleaner to me. I just hope I don't start writing lots of unnecessary fluent rubbish:

   1: Increase.The(principalBalance).By(theTransaction.Amount);

I'm just reading Pete Goodliffe's Code Craft. I'm only at the beginning of the book and he's devoted a chapter to coding standards, reinforcing my own belief that good code presentation goes a long way towards good code.

One of the things he neglects, I believe, is adding the reason why to each specific point of the standard. This might seem like a whole bunch of unnecessary nit picking, but here me out.

I'm an inquisitive chap. I flat out refuse to accept anything anyone says as an absolute truth without some context or background. In a lot of cases, this can tell you a lot about the person making these statements.

I think providing a "why" to each rule of the standard gives context and background helping to coerce people who might otherwise be hostile to the rule, and to give those with a legitimate argument against it more of a backdrop to better formulate their argument, which could lead to a better standard in the end anyway.

For example, the underscore rule I've adopted for private/protected fields (fields considered internal to the class and it's subclasses).

I'll declare them like so (in C#):

   1: protected string _firstName;

Then anything public (fields externally visible from the class) I'll declare like this:

   1: public string LastName;

(Forgetting automatic properties/should I use properties at all/etc)

Now, my reasoning behind this is simple. The first part is; I don't like hungarian notation. I don't think it's relevant anymore; and people don't use it in the way it was intended to be used (scroll down to "I'm Hungary"), anyway. Not only that, it adds extra characters when you type variables that detract from the beauty of simple code. What looks better, this:

   1: private string m_sFirstName;

or

   1: private string _firstName;

the "m_" is redundant, as you can only have member variables in classes in .NET anyway, so there's two characters saved; and the "s" is tying the type of the data to a string. What happens if it's a string buffer and you later want to change it to a StringBuilder instance? Are you going to go through your entire code base and replace every "s" with an "sb"? If you are, you're in for a long day for a simple decision, and if you don't you're breaking the point of the hungarian and people will learn not to trust it.

The second part (and more to the point, anyway) relates to the case-sensitivity of languages. Let's say you're writing your library in C#, and one of the consumers of your library is using VB. VB is a not case-sensitive. There's no conceptual difference to VB between the two following declarations:

   1: protected string firstName;

   2: public string FirstName { get; set; }

The underscore is the simplest possible way to better differentiate the internal fields from the external ones.

So, there you have the why. You may already have some good arguments as to why I should change my mind, or even have a better solution to the problem. The point is, it's no longer related to ego, but an honest reason. It's not religious, and I won't be hurt if you suggest something different, as long as it also has a valid "why".

If you can't think of one, then be prepared to change it and be man (or woman) enough to admit that it was that way simply because you wanted it that way.

Don't. Well, don't if you're building an ASP.NET application that's going to run in a walled off environment on a shared server.

Why?

Well, it's an interesting issue of security, you see. Strange isn't it, that the Data Protection API has security issues?

Using the DPAPI requires access to a key container. This is where any keys created by the DPAPI are stored so they can be used to encrypt and decrypt data. There are two types of key containers in the DPAPI. User-level and machine-level. By default, the DPAPI uses a user-level key container.

The user-level key container is stored in the user's profile. When you use the DPAPI for a standard Windows-based (WinForms/WPF etc) application, you won't run into any trouble. When you try to use it in an ASP.NET application you'll hit some hurdles, but you won't notice until you put it into production. Unless you've read this.

The trick here is the fact that the user-level key container is stored in the user's profile. When you're developing an ASP.NET application, the application runs under the logged-in user's profile (yours). There's a key container available, and all the lovely encryption goodies work.

When you put the application into a production environment, regardless of the user context you setup for the worker process group, it will fall apart. The user that ASP.NET is set to run under never logs in. And this is an important point. This means the user profile is never loaded, so you have no user-level key container available to store the keys that you create. You'll find this out thanks to a wonderfully ambiguous and unhelpful exception.

If you're like me (and lets face it, who isn't?) you'll be straight onto Google searching on the error message. You'll track down a lovely knowledge-base article (which I don't have the link for, sorry...) that tells you the simple work around is to specify that the DPAPI should use the machine key store. It's a simple property called something like UseMachineKeyStore (I kid you not) and you set it to true. There's one more thing, and that's a policy permission you'll need to set on the user account the WPG runs under to allow it access to the machine key container.

And therein lies the rub.

Firstly, the machine key store is a machine-wide resource. If an application crashes or is compromised in some way, the crashed app/compromisor has access to a machine level resource that contains some incredibly sensitive information! Not only that, there's the potential attack vector that arises, as well as the ability to abuse the API and cause the machine to crash effecting a denial-of-service.

Secondly, you've had to elevate the permissions of the user account that the application is running under. The idea is to have the least amount of permissions possible for these user accounts to close the door as much as we can. Allowing the user account access to the machine key store is like hanging your underwear on your front porch. Before you've washed it.

Okay, what can I do about that?

Simple. You'll have to stump up for a third party library that will do the same trick for you. Make sure it doesn't just wrap the MS DPAPI, and that it uses standard and verifiable algorithms for the encryption and key generation.

A library I've used to solve this problem is from Chilkat Software. The website looks like a clearance sale ad for ski gear come summer, and I think the licensing mechanism could've been better thought out, but the components themselves are extremely well put together.

You can use a library like this to generate RSA encryption keys and encrypt and decrypt strings that can be read by any other standards following library (including the MS DPAPI).

These components run in-process in the exact same way as any code you've written for the application does. They don't require access to any key containers, or elevated permissions for any users.

Note: I have no association with Chilkat outside the fact that I've bought and used these components.