Have you ever wondered whether it is possible to create your own collection initializers just like for the List<T>?

var list = new List { 12, 42, 256, 1024 };

Well… doing that is actually extremely simple. All your custom object needs is a public Add method that takes whatever arguments you might want. Don’t try to analyze the code, I know that it doesn’t make any sense at all – it’s just an example

public class MyCollection : IEnumerable
{
	private List _list = new List();

	public void Add(Predicate predicate, T trueValue, T falseValue)
	{
		_list.Add(new MyIfThen { Predicate = predicate, TrueValue = trueValue, FalseValue = falseValue });
	}

	public struct MyIfThen
	{
		public Predicate Predicate;
		public T TrueValue;
		public T FalseValue;
	}

	#region IEnumerable Members

	public IEnumerator GetEnumerator()
	{
		return _list.Select(ifthen => ifthen.TrueValue).GetEnumerator();
	}

	#endregion

	#region IEnumerable Members

	System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
	{
		GetEnumerator();
	}

	#endregion
}

...

var mine = new MyCollection
		   {
			   {i => i%2 == 0, 12, 42},
			   {i => i%3 == 0, 33, 66},
		   };

That one recently cost me a couple of hours and quite a bit of nerves to figure out: In a 64bit Windows, if a 32bit process accesses the Registry, it actually interacts with a DIFFERENT registry than a 64bit process. This means that your 32bit compiled program potentially reads and writes different registry keys than the same program compiled for 64bit! I’m sure you can imagine how this might result in seemingly strange behavior if you don’t know that. Windows Registry FTW, right?

Since regedit.exe runs as a 64bit process, you can usually only see the 64bit registry, but what if you want to see/change 32bit entries? It turns out you can do that if you know how this registry redirection works. In every node in the (64bit) registry there CAN be a child node with the name “WOW6432Node” that contains the 32bit entries that override/amend the 64bit entries. The only WOW node that I could find in my registry was in HKLM\SOFTWARE, but the concept works for every other part of the registry.

Source: http://msdn.microsoft.com/en-us/library/aa384253%28v=vs.85%29.aspx

Those of you familiar with Linux systems should know the very helpful “which” command which can tell you where exactly an executable that is in your PATH is located. The good news is, that a very similar command exists in PowerShell

> get-command tf

If the TFS exectuable is in your path, this gives you output of the form.

CommandType     Name                     Definition
-----------     ----                     ----------
Application     TF.exe                   C:\Program Files\Microsoft Visual Studio 9.0\Com...

But that’s not very helpful, is it? I mean, a quite important part of the path is cut off for crying out loud. So how do you get the FULL path?

> get-command tf | format-list

Name            : TF.exe
CommandType     : Application
Definition      : C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\TF.exe
Extension       : .exe
Path            : C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\TF.exe
...

And there you go. It’s a bit more complicated than necessary, but at least it’s possible.

To install Windows 7 on a virtual disk, follow these instructions.

• Boot from the Windows 7 installation disc
• Press SHIFT+F10 to open the command prompt
• Start diskpart.exe
• If you already haven’t already created a vdisk that you would like to install Win7 on, create one (see previous post)
• Attach the virtual disk

  > select vdisk file="C:\path\to\vhd"
> attach vdisk
> exit

• Continue with the installation by selecting “Custom Install”
• Select the virtual disk (if you have formatted and named your disk, you will see that name now, otherwise you will have to consider the disk size)
• Install Windows 7

The installer will create a boot menu entry for your new Windows installation and your existing non-virtual installation. Unfortunately, they are (by default) both called “Windows 7”. Very helpful… The virtual installation will be the first entry in your boot menu and started by default. Once your installation is complete, you can fix this issue with the “bcdedit.exe” command line tool.

Open a command prompt as administrator and follow these steps:

> bcdedit.exe

This will give you a list of all boot manager entries. Find the one that refers to your VHD file and copy it’s ID – {current} if you are currently running your virtual installation and usually {default} if you’re running the physical installation.

> bcdedit.exe /set description "New boot menu entry"

You can also create copies of your bood menu entries and adjust them to, let’s say, point to a different VHD file.