FxCop gives interesting advice. With it's help I've gone from a very simple and incorrect...
using System;
namespace calc

To a much more impressive and correct...
using System;
using System.Reflection;
using System.Security.Permissions;
using System.Globalization;
[assembly:CLSCompliant(true)]
[assembly: AssemblyVersionAttribute("0.9.0.0")]
[assembly: System.Runtime.InteropServices.ComVisible(false)]
[assembly: SecurityPermission(
SecurityAction.RequestMinimum, Execution = true)]
[assembly: PermissionSet(
SecurityAction.RequestOptional, Name = "Nothing")]
namespace Calc

What all this means is as follows:
[assembly:CLSCompliant(true)]
This marks the code as CLS Compliant

using System.Reflection;
[assembly: AssemblyVersionAttribute("0.9.0.0")]
Allows versioning by adding an instance of AssemblyInfo.cs. This is also seems to be where you can specify a keyfile for strong naming.

using System.Security.Permissions;
[assembly: SecurityPermission(
SecurityAction.RequestMinimum, Execution = true)]
[assembly: PermissionSet(
SecurityAction.RequestOptional, Name = "Nothing")]
Marks the code as having the minimal security permissions.

[assembly: System.Runtime.InteropServices.ComVisible(false)]
The code is not COM visible.

using System.Globalization;
Allows for some culture info to be used when converting strings to double sor vice versa. Nice to be told about this now, before I decide to sell my calculator in France. :)

And finally...
namespace Calc
The namespace identifier should use PascalCase. Tut, tut.

It's a fairly impressive start to a program, and I can understand why they keep all this out of all the simple example code you see. The other recommendation is that the assembly should have a strong name, which is definitely something I should look into.

FxCop. A very nice utility indeed... 

FxCop

I downloaded FxCop and installed it. It is something like NuMega Code Review.

I opened my calculator project .dll and ran the FxCop analysis...

FxCop scans the code and checks it against it's built in rules database which is based on Microsoft's .NET Framework Design Guidelines.

Apparently there are 1370 rules to follow, so I forgive myself for making 12 mistakes. The code review is very helpful, for each problem it finds it tells you how critical the fault is and provides a link to a help page that tells you how to resolve the problem. This is a very good way to learn about the design guidelines.

For example, it picks up on any instances where you have used the wrong case for identifiers. Obviously the more experience you have the fewer issues there should be. Definitely something to run regularly before checking code in.