C# 3.0 – Part II :: Object & Collection Initializers

In part I, the feature discussed was auto-implemented properties. Here we’ll make use of the classes defined in part I to demonstrate object initializers.

Notice that no constructor was declared in the classes defined. The compiler creates a default constructor (empty constructor), but this isn’t new in 3.0. What is new, is a way to set the properties of the object as it is initialized.

// declare and initialize an instance of the Address class
Address homeAddress = new Address()
{
// set the properties using C# 3.0 object initializer feature
Street = "123 Some Street",
City = "Newport Beach",
State = "CA",
PostalCode = "92626",
AddressType = AddressType.Home
};

We can then use the homeAddress instance to instantiate a Person object, also defined in part I.

Person person = new Person()
{
ID = 1,
FirstName = "John",
LastName = "Doe",
Addresses = new List<Address>(){ homeAddress }
};

Notice that we’ve initialized the collection of addresses of the person instance, as the object itself is initialized. Collection Initializers is also a new feature of C# 3.0. Instead of calling the Add method of a collection, we can simply list the objects, similar to that of arrays.

We can even combine the initialization of objects and collections into one big block of code.

Person person = new Person()
{
ID = 1,
FirstName = "John",
LastName = "Doe",
Addresses = new List<Address>()
{
new Address()
{
Street = "123 Some Street",
City = "Newport Beach",
State = "CA",
PostalCode = "92626",
AddressType = AddressType.Home
}}};

Probably the most interesting to me are the collection initializers. I’ve often have had to create lookup dictionaries for one reason or another. Typically the process is declare and instantiate the dictionary and then populate with lookup values.

Dictionary<int, string> numberLookup = new Dictionary()<int, string>();
numberLookup.Add(1, "one");
numberLookup.Add(2, "two");

Instead, we can instantiate like so:

Dictionary<int, string> numberLookup = new Dictionary()<int, string>()
{
{ 1, "one" },
{ 2, "two" }};

C# 3.0 – Part I :: Auto-Implemented Properties

I’ve been playing around with VS 2008 and looking at some of the new features implemented for the next version of C#. Here’s some features that I found to be time saving.

Auto-Implemented Properties
Encapsulating properties has always been a pain, even with code snippets. C# 3.0 allows the declaration of backing fields with auto implemented properties, as shown below.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Sample
{
public class Person
{
public int ID { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
public List<Address> Addresses { get; set; }
}

public class Address
{
public string Street { get; set; }
public string City { get; set; }
public string State { get; set; }
public string PostalCode { get; set; }
public AddressType AddressType { get; set; }
}

public enum PhoneType
{
Home,
Work,
Fax,
Mobile
}

public enum AddressType
{
Home,
Work
}
}

I added a an enumeration and List of addresses to play with collections later. A caveat to the auto-implemented properties is that you can’t have complex get or set accessors and mutators. You’re probably thinking what’s the point? You can get the same thing with making the backing fields themselves public. I agree that the use is limited; however, there is that option to make the mutator private in order to make the property read only. The feature isn’t ground breaking but it does save some time when you’re making some simple container class.

Special Folders

Ever wonder where certain special folders map to? There’s the enumeration System.Environment.SpecialFolder and the special folders in a Visual Studio setup project to name a couple. When you’re using them in your code or setting up a deployment project, how do you know that the special folder you’re using is actually what you want?

Well I got tired of running the app to see if it will break or making a small application to test what folder does it actually map to. Hence I wrote a small app and iterateded through the enumeration to get the folder paths using
Environment.GetFolderPath(Environment.SpecialFolder)
Environment.SpecialFolder

Enumeration Value	Vista (32 bit)
Desktop	C:\Users\{username}\Desktop
Programs	C:\Users\{username}\AppData\Roaming\Microsoft\Windows\Start Menu\Programs
Personal	C:\Users\{username}\Documents
Favorites	C:\Users\{username}\Favorites
Startup	C:\Users\{username}\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
Recent	C:\Users\{username}\AppData\Roaming\Microsoft\Windows\Recent
SendTo	C:\Users\{username}\AppData\Roaming\Microsoft\Windows\SendTo
StartMenu	C:\Users\{username}\AppData\Roaming\Microsoft\Windows\Start Menu
MyMusic	C:\Users\{username}\Music
DesktopDirectory	C:\Users\{username}\Desktop
Templates	C:\Users\{username}\AppData\Roaming\Microsoft\Windows\Templates
ApplicationData	C:\Users\{username}\AppData\Roaming
LocalApplicationData	C:\Users\{username}\AppData\Local
InternetCache	C:\Users\{username}\AppData\Local\Microsoft\Windows\Temporary Internet Files
Cookies	C:\Users\{username}\AppData\Roaming\Microsoft\Windows\Cookies
History	C:\Users\{username}\AppData\Local\Microsoft\Windows\History
CommonApplicationData	C:\ProgramData
System	C:\Windows\system32
ProgramFiles	C:\Program Files
MyPictures	C:\Users\{username}\Pictures
CommonProgramFiles	C:\Program Files\Common Files