I just noticed that I am getting more space on my Gmail account (6 Gig) and while I am grateful I am wondering what percentage of the account totals people actually use. As you can see I am just about touching 4% and that is after several years of use.

Now if I could use my left over space in a SkyDrive like fashion i.e. being able upload files for storage, I believe that the additional space would be actually useful.

How much Gmail space are you using?

After a fielding a few questions about security in some recent projects, I was looking at couple of ways that security is handled within the .NET framework. I wanted to figure out how you could define, method by method, whether a user had permission to run a method within their security context..

The two methods I focused on are Windows Principal and Principal Permission.

Windows Principal
At a basic level we could implement code that verifies what role the current user is based upon. This method is clean and simple! Throw this at the front of each method and your golden ... but that is not very elegant.

WindowsIdentity ident = WindowsIdentity.GetCurrent();
WindowsPrincipal user = new WindowsPrincipal(ident);
if(user.IsInRole("Admin")){
    //Do stuff here...
}

The Principal Permission
In the following example we have applied PrincipalPermissionAttribute which declaratively requires the user running the code to belong to a specific role or to have already have been authenticated. I learned the hard way that you also need to explicitly set the Principal Policy before calling the method or class with a permission attribute.

    using System.Security;
    using System.Security.Permissions;
    using System.Security.Principal;
    using System.Threading;

    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);

                MyTest mt = new MyTest();
                Console.WriteLine(mt.GetMessage());
            }
            catch(SecurityException ex)
            {
                Console.WriteLine(ex.Message);
            }
            Console.ReadLine();
        }
    }

    class MyTest
    {
        public MyTest() {Console.WriteLine("Start MyTest"); }

        [PrincipalPermissionAttribute(SecurityAction.Demand, Name = @"Domain\Admin")]
        public string GetMessage()
        {
            return "My Message";
        }
    }

I often check the statistics of my blog to see what posts garner the most attention. I was hoping for a more technical blog to be the most popular, but it appears that a throw a way article on the Performance Reviews appears to get hit every single day.

In some countries it is apparently within that lucrative top 10 Google search!

The idea behind collections is concurrently convenient and fraught with potential conversion problems. Collections are designed to store all things given to them as objects and therefore filling a collection is cake.

For example:

ArrayList MyList = new ArrayList();

MyList.Add(8);

MyList.Add(9);

MyList.Add("10"); //wait this is a string ... but it is perfectly legal as everything is stored as an object.

The fundamental idea is you can place multiple variable types in a single collection conveniently, without regard for all that is type safe or type sane. The problem is ultimately revealed when we unwrap our collection and expose it to the real type safe world of .NET programming.

We end up with:

int int8 = (int)MyList[0];

int int9 = (int)MyList[1];

int int10 = (int)MyList[2]; //but wait this is a string!

…but the compiler can never know because collections are all objects and this will not become apparent until run time (usually in QA or worse yet in Production).

This simple example now requires the programmer to continually track what types are associated with which element of the ArrayList which invariably leads to complex and custom type checking solutions.

.NET 2.0 to the rescue:

Our friends at Microsoft have provided us with a Generic List (Systems.Collections.Generic) that can be type safe. Our code now becomes

List<int> MyNewList = new List<int>() //<int> tells the compiler that this is a generic collection of type int.

MyNewList.Add(8);

MyNewList.Add(9);

MyNewList.Add("10"); \\this is still a string but this can be caught immediately

The problematic line of code can now be caught safely by the compiler before ever going to QA, production, or even you own unit testing.

After Robert mentioned that we will be moving to a newer version of the .NET framework, I wanted the opportunity to look at some of the language improvements of .NET 2.0 specifically the use of nullable types.

There are two main types that we generally deal with, reference and value types. These two types are treated and stored differently and as a result we have specific behaviors that go along with these types. The main difference I would like to highlight is the fact that value types cannot be null.

So for example:-

int x = 0; //legal
int x = null; // not so legal "Cannot convert null to 'int' because it is a value type"
string s = "hello"; //legal
string s = null; //legal

The surface response is that integers are never null ... but development with XSD and Sql Server allows  us to have nullable integers. So there are legitimate reasons to have a strong solution for this problem of null values.

The first way we could do this is to actually create a class that wraps round the integer type. This class would support a series of methods that would checks for Null values. I saw a great VB 6 developer do a similar thing. However, this approach is made redundant in .NET 2.0.

Nullable Template:
The more appropriate way to do this would be to use the new Nullable struct This gives us the following:

Nullable<int> i = null; //legal

We can also use HasValue to determine whether the current value is null as follows:

Nullable<int> i = null
if(i.HasValue)  //(also i==null would work)
{
    int j = (int)i;
}

This can be rewritten as follows:

int? i = null; // int ? => nullable int
int j = i ?? 0;

Check the last two snippets of code out in ILDASM. It really amounts to the same thing.

Microsoft's online MSDN documentation has, for some time, offered a very intuitive way of discovering information about various classes and namespace via direct input into the URL. Effectively you can guess what the location of things you want to look up.

I can for example type the following URL in my browser http://msdn2.microsoft.com/en-us/library/system.io, and get directed to the System.IO namespace documentation. Similarly I can get directly to information on classes by using the same technique. http://msdn2.microsoft.com/en-us/library/system.data.odbc.odbcerror, takes me directly to OdbcError class.