Originally, I was going to focus on shortcuts for the various build/compilation options within Visual Studio 2008.  However, things become a little more complicated in terms of which keyboard shortcut to use because it depends on your keyboard mapping scheme.  In this edition, therefore, I am going to discuss the Keyboard Options dialog - where different keyboard schemes are available for selection. 

During the first launch of Visual Studio 2008, you are prompted with which keyboard scheme to use.  The typical options are (Default), Visual C# 2005, and Visual Basic 6. Fortunately, you can change your selection via the Tools->Customize... menu and the Keyboard... button on the ensuing dialog (Alt+T, Alt+C, Alt+K). The same dialog is available from Tools->Options... and the Keyboard node of the environment.

The first dropdown on the right hand side of the dialog is where you can change your keyboard mapping scheme.  (In this write-up, we will ignore the left hand tree of the dialog except to say the same dialog is used for the rest of Visual Studio's options as well.)  After selecting which scheme you want, push Reset (Alt+E) to have all the keyboard settings for the selected scheme mapped. 

Once you have the scheme you want, type within the Show commands containing text box.  Notice that the commands list automatically filters down to those which contain the value entered anywhere within the name.  In the screen shot above, "build" is used to filter the commands to those that have "build" in them.  There are numerous functions within Visual Studio that do not map to menu options and, therefore, there is no intuitive way to know of their existence except from the Keyboard Options or the Customize... options dialog.  The Show commands containing text box makes finding commands relatively easy, however. Consider, for example, determining the keyboard shortcut for deleting the current line.  In the Show commands containing text box, type "delete" or "line" and then browse through the available commands to discover that such a command exists (Edit.LineDelete) and that by default Ctrl+Shift+L will invoke it.

Within the list of commands, you can select one of the commands and view the shortcut it is mapped to, if any.  Build.BuildSelection is shown here to map to Shift+F6 (Global), where "Global" here means that this keystroke will work regardless of the context within Visual Studio (such as whether the Text Editor or Class Designer windows are active).  It is helpful to browse through the various commands and see what they are mapped to.  Furthermore, if you wish to map a new or different keystroke, you can type it in the Press shortcut keys text box.  What is helpful, is that if the key typed already has a mapping, the existing mapping will show up in the Shortcut currently used by text box, allowing visibility as to whether you want to change the mapping or perhaps select a different keyboard shortcut.

In summary, the Keyboard Options dialog is a great technique within Visual Studio for determining what commands are available, what commands are mapped to which keyboard shortcuts, and for mapping new keyboard shortcuts to the commands.

Frequently, while browsing code, we want to drill down into a method to see the implementation and then jump back out again to continue browsing code at the caller. One invaluable keystroke for doing this is F12. Placing your cursor on any identifier, you can use F12 to drill into its declaration. This works both for types as well as their members. In fact, you can use the same keystroke to jump to the definition of types in the .NET Framework. This is a great way to browse through the type's members to see header information, including the documentation of the parameters. To jump back, you can use Ctrl+-. In this way you can navigate back and forth through your code.

As quoted from a post by me on MSDN Flash, Nov 17, 2007.

A recent install of Team Foundation Explorer errored out.  Opening the log file (from the link on the error screen) and scrolling to the bottom, showed the following:

[07/16/08,15:39:33] Microsoft Visual Studio 2008 Team Explorer - ENU: CRootComponent::Install(): Beginning Brooklyn Component Installation
[07/16/08,15:39:33] Setup.exe: ISetupManager::GetFullComponents()
[07/16/08,15:39:33] Setup.exe: ISetupManager::GetFullComponents()
[07/16/08,15:39:34] DepCheck: gencomp97,{12CDA52C-7A8F-4785-8A22-53C87393FEE0}
[07/16/08,15:39:34] DepCheck_Result: 1
[07/16/08,15:39:34] Microsoft Visual Studio 2008 Team Explorer - ENU: Install(): bAttemptInstall: 0
[07/16/08,15:39:34] Microsoft Visual Studio 2008 Team Explorer - ENU: Install(): Not attempting to call MsiInstallProduct()!!!! Baseline not met!
[07/16/08,15:39:34] Setup.exe: AddGlobalCustomProperty
[07/16/08,15:39:34] Microsoft Visual Studio 2008 Team Explorer - ENU: CRootComponent::Install(): Setup Failed; MSIInstallProduct return value either ERROR_INSTALL_FAILURE or default.
[07/16/08,15:39:34] Setup.exe: AddGlobalCustomProperty
[07/16/08,15:39:34] Microsoft Visual Studio 2008 Team Explorer - ENU: CRootComponent::Install(): Calling LaunchWatson()...
[07/16/08,15:39:34] Microsoft Visual Studio 2008 Team Explorer - ENU: CRootComponent::LaunchWatson() - Obtained CSetupWatson instance
[07/16/08,15:39:34] Setup.exe: GetGlobalCustomProperty - Property: {AA62DF98-3F2C-11D3-887B-00C04F8ECDD6} - PropertyName: Maintenance Mode - Value: 0
[07/16/08,15:39:34] Microsoft Visual Studio 2008 Team Explorer - ENU: CRootComponent::LaunchWatson() - Launching VS Watson
[07/16/08,15:39:34] Microsoft Visual Studio 2008 Team Explorer - ENU: CRootComponent::LaunchWatson() - Completed VS Watson launching to create manifest: C:\DOCUME~1\mmichael\LOCALS~1\Temp\vs_setup.dll.txt
[07/16/08,15:39:34] Setup.exe: AddGlobalCustomProperty
[07/16/08,15:39:34] Microsoft Visual Studio 2008 Team Explorer - ENU: CRootComponent::LaunchWatson() - Setting the property CustomCoreProp_WatsonManifestReady to use the VS Client Manifest.
[07/16/08,15:39:34] Microsoft Visual Studio 2008 Team Explorer - ENU: CRootComponent::Install(): Finished calling LaunchWatson()
[07/16/08,15:39:34] Microsoft Visual Studio 2008 Team Explorer - ENU: CRootComponent::Install(): Finished Brooklyn Component Installation
[07/16/08,15:39:34] UTILS::RunNGENAction: Started
[07/16/08,15:39:34] UTILS::RunNGENAction: starting "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ngen.exe queue pause"
[07/16/08,15:39:34] UTILS::RunNGENAction: ngen.exe returned 0
[07/16/08,15:39:34] Setup.exe: AddGlobalCustomProperty
[07/16/08,15:39:34] setup.exe: ***ERRORLOG EVENT*** : ISetupComponent::Pre/Post/Install() failed in ISetupManager::InternalInstallManager() with HRESULT -2147023293.
[07/16/08,15:39:35] Setup.exe: GetGlobalCustomProperty - Property: {7F82DEDD-12EB-439F-B7A3-8B4264E0C20D} - PropertyName: EnableRollback - Value:
[07/16/08,15:39:35] Setup.exe: GetGlobalCustomProperty - Property: {BD495746-4FBA-49F3-8EEB-D8B20EE75235} - PropertyName: Disable Rollback - Value:
[07/16/08,15:39:35] Setup.exe: ISetupManager::RunInstallFromList(IP_INSTALL) completed
[07/16/08,15:39:35] Setup.exe: GetGlobalCustomProperty - Property: {092114C2-997D-4D68-8F3A-8BC2584FD23B} - PropertyName: Quiet Mode Setup - Value:
[07/16/08,15:39:35] TFSUI: ISetupManager::GetGlobalCustomProperty() failed to find global prop in CProgressPage::RunningComponent()
[07/16/08,15:39:35] TFSUI: {4F8791EE-486F-44B5-952B-F28F9FD58BD0}

Working with Dhathri Potla, I identified two issues:

1. The HRESULT error indicates that there was a problem reading the media.  I had mounted and ISO file of Visual Studio 2008 with the TFC (Team Foundation Client) directory and attempted the install from there.  The ISO file itself was stored on a network share.  To avoid this error, copy the TFS directory onto the local drive.
2. “Baseline not met” indicates the prerequisites for TFC were not installed successfully.  Probably due to issue #1.

You can navigate to the TFS\WCU directory and manually install the prerequisites within each subdirectory and then retry the install.  However, as in my case, there prerequisites appeared to install correctly individually and yet the overall install log file showed that there were still prerequisites missing.  To address this, uninstall the prerequisites (like document explorer or Premier Partner Edition - PPE) and the re-run the TFS setup.exe.

While searching for the command line to change the password expiration policy, I came across http://www.joeware.net/freetools.  Here are a bunch of free tools for Windows Administration from the command line.  Many of them already have command line equivalents, but I suspect these versions are significantly easier.

Many moons ago I discussed the foreach loop.  I expand on that post here as I continue my series for the MSDN C# Developer Center.

The advantage of a foreach loop over a for loop is the fact that it is unnecessary to know the number of items within the collection when an iteration starts. This avoids iterating off the end of the collection using an index that is not available. As Bill Wagner pointed out in his Custom Iterators article last week, a foreach loop also allows code to iterate over a collection without first loading the collection in entirety into memory. In this article I am going to explore how the foreach statement works under the covers. This sets the stage for a follow on discussion of how the yield statement works.

foreach with Arrays

Consider the foreach code listing shown in Listing 1:

Listing 1: foreach with Arrays

int[] array = new int[]{1, 2, 3, 4, 5, 6};
foreach(int item in array)
{
     Console.WriteLine(item);
}

From this code, the C# compiler creates CIL equivalent of a for loop like this (Listing 2):

Listing 2: Compiled Implementation of foreach with Arrays

int[] tempArray;
int[] array = new int[]{1, 2, 3, 4, 5, 6};
tempArray = array;
for (int counter=0; (counter < tempArray.Length); counter++)
{
     readonly int item = tempArray[counter];
     Console.WriteLine(item);
}

Since the collection is an array and indexing the array is fast, the foreach loop implementation relies on support for the Length property and the index operator ([]). However, these two array features are not available on all collections. Many collections do not have a known number of elements and many collection classes do not support retrieving elements by index.

foreach with IEnumerable<T>

To address this, the foreach loop uses the System.Collections.Generic.IEnumerator<T>. (Given C# 2.0’s generics support, there is very little reason to consider using the non-generic equivalent collections so I will ignore them from this discussion except to say their behavior is almost identical.) IEnumerator<T> is designed to enable the iterator pattern for iterating over collections of elements, rather than the length-index pattern shown in earlier. IEnumerator<T> includes three members. The first is bool MoveNext(). Using this method, we can move from one element within the collection to the next while at the same time detecting when we have enumerated through every item using the Boolean return. The second member, a read-only property called Current, returns the element currently in process. With these two members on the collection class, it is possible to iterate over the collection simply using a while loop as demonstrated in the code listing below (Listing 3):

Listing 3: Iterating over a collection using while

System.Collections.Generic.Stack<int> stack =
     new System.Collections.Generic.Stack<int>();
int number;
// ...
// This code is conceptual, not that the actual code.
while(stack.MoveNext())
{
     number = stack.Current;
     Console.WriteLine(number);
}

The MoveNext() method in this listing returns false when it moves past the end of the collection. This replaces the need to count elements while looping. (The last member on IEnumerator<T>, Reset(), will reset the enumeration.) This while listing shows the gist of the C# compiler output, but it doesn’t actually work this way because it omits two important details about the actual implementation: interleaving and error handling.

Interleaving

The problem with is that if there are two (or more) interleaving loops over the same collection, one foreach inside another, then the collection must maintain a state indicator of the current element so that when MoveNext() is called, the next element can be determined. The problem is that one interleaving loop can affect the other. (The same is true of loops executed by multiple threads.)

Figure 1: IEnumerable class diagram

To overcome this problem, the IEnumerator<T> interfaces are not supported by the collection classes directly. As shown in Figure 1, there is a second interface called IEnumerable<T> whose only method is GetEnumerator(). The purpose of this method is to return an object that supports IEnumerator<T>. Rather than the collection class maintaining the state itself, a different class, usually a nested class so that it has access to the internals of the collection, will support the IEnumerator<T> interface and keep the state of the iteration loop. Using this pattern, the C# equivalent of a foreach loop will look like what's shown in Listing 4.

Listing 4: A separate enumerator maintains state during an iteration

System.Collections.Generic.Stack<int> stack =
     new System.Collections.Generic.Stack<int>();
int number;
System.Collections.Generic.Stack<int>.IEnumerator<int>  enumerator;

// ...
// If IEnumerable<T> is implemented explicitly,
// then a cast is required.
// ((IEnumerable)stack).GetEnumeraor();
enumerator = stack.GetEnumerator();
while (enumerator.MoveNext())
{
     number = enumerator.Current;
     Console.WriteLine(number);
}

Error Handling

Since the classes that implement the IEnumerator<T> interface maintain the state, there are occasions when the state needs cleaning up after all iterations have completed. To achieve this, the IEnumerator<T> interface derives from IDisposable. Enumerators that implement IEnumerator do not necessarily implement IDisposable, but if they do, Dispose() will be called as well. This enables the calling of Dispose() after the foreach loop exits. The C# equivalent of the final CIL code, therefore, looks like Listing 5.

Listing 5: Compiled Result of foreach on Collections

System.Collections.Generic.Stack<int> stack =
     new System.Collections.Generic.Stack<int>();
int number;
System.Collections.Generic.Stack<int>.Enumerator<int> enumerator;
IDisposable disposable;
enumerator = stack.GetEnumerator();

try
{
     while (enumerator.MoveNext())
     {
          number = enumerator.Current;
          Console.WriteLine(number);
     }
}
finally
{
     // Explicit cast used for IEnumerator<T>.
     disposable = (IDisposable) enumerator;
     disposable.Dispose();

     // IEnumerator will use the as operator unless IDisposable
     // support determinable at compile time.
     // disposable = (enumerator as IDisposable);
     // if (disposable != null)
     // {
     // disposable.Dispose();
     // }
}

Notice that because the IDisposable interface is supported by IEnumerator<T>, the C# code can be simplified with the using keyword as shown in Listing 6.

Listing 6: Error handling and resource cleanup with using

System.Collections.Generic.Stack<int> stack =
     new System.Collections.Generic.Stack<int>();
int number;

using(
     System.Collections.Generic.Stack<int>.Enumerator<int> enumerator =
          stack.GetEnumerator())
{
     while (enumerator.MoveNext())
     {
          number = enumerator.Current;
          Console.WriteLine(number);
     }
}

However, recall that the using keyword is not directly supported by CIL either, so in reality the former code is a more accurate C# representation of the foreach CIL code.

Readers may recall that the compiler prevents assignment of the foreach variable identifier (number). As is demonstrated in Listing 6, an assignment of number would not be a change to the collection element itself so rather than mistakenly assume that, the C# compiler prevents such an assignment altogether.

In addition, the element count within a collection cannot be modified during the execution of a foreach loop. If, for example, we called stack.Push(42) inside the foreach loop, it would be ambiguous whether the iterator should ignore or incorporate the change to stack – should iterator iterate over the newly added item or ignore it and assume the exact same state as when it was instantiated.

Because of this ambiguity, an exception of type System.InvalidOperationException is thrown if the collection is modified within a foreach loop, reporting that the collection was modified after the enumerator was instantiated.

(This content was largely taken from the Collections chapter of my book, Essential C# 2.0 [Addison-Wesley])

Today I received an email asking how to associate a work item with a changeset after all the code was checked in (without performing the association.)

It turns out the solution is relatively simple.  On the Links tab of the work item select Add.  By default, this shows the Link Type is set to Work Item.  However, you can change the type to Changeset and then browse for the changeset(s) you wish to associate with the code.

(The browse functionality is a good reason why you always want to include comments with your check-in.)