Way back in July I wrote a blog post explaining why I switched from Windows Vista to Windows Server 2008 (WS2008) as the primary OS for my laptop. Well I’ve lived with WS2008 for a few months now, and although there are more than a few inconveniences associated with it, I still think the advantages outweigh the disadvantages, at least for the work that I do. As I installed WS2008 on my laptop I made notes, thinking this might be useful information, not only for the next time around, but also to share with my compatriots in the blog-o-sphere.

I recently purchased a Dell XPS M1530 laptop with all the bells and whistles: T9300 processor, 4GB RAM, 320GB 7200 RPM internal SATA drive, and hi-res glossy widescreen display. This time I decided to leave Windows Vista on the machine to play games and movies and enjoy all the other consumer candy that comes with it. So, I installed WS2008 in a dual-boot configuration, with WS2008 being the default OS. To do this, though, I had to make room on the internal hard drive. I wanted to devote as little space to Vista as possible because I didn’t expect to use it much. Vista was consuming about 15GB, so I figured that shrinking it’s partition down to 30GB would be more than sufficient. Much to my surprise though, the Disk Management utility in Vista was not willing to shrink the volume below 150GB. WTF!

A bit of investigation lead me to this article. Based on its advice I defragged and optimized the volume using a 15-day free trial of Perfect Disk 2008. But some system files simply refused to move from the middle of the Vista volume. So, I did what any rational person would do: give up. I ended up with a 150GB Vista partition with gobs of free space. Arggh. As it turns out though, the Vista volume mounts as drive D in WS2008, so I decided to use all that extra space in the Vista volume (drive D) to store the huge virtual hard disk files (VHDs) for the Hyper-V virtual machines I would be installing later. Problem solved!

The WS2008 installation went smoothly. The WS2008 installer even set up the dual boot menu to appear on startup, with WS2008 as the default selection. Perfect!

In the next installment I’ll share the steps I used to install and configure Windows Server 2008 Standard Edition as a laptop OS.

I recently had to go through the process of installing Visual Studio 2008 with a team getting ready to use Visual Studio Team System and Team Foundation Server. Further, I have been tinkering with Silverlight 2 recently and this has even more tooling around it.

Based on this experience, I thought I would outline the installed components. You'll see that it takes awhile to get through all of this.

Keep in mind, this is the install for the client side. Not the server or the build machine.

1. Visual Studio Team System 2008 basic install.
   This can be Team Suite, Developer, Tester, whatever. See your MSDN subscription or DVD media for this.
2. Team Explorer 2008
3. Visual Studio Team System 2008 Team Foundation Server Power Tools
4. Visual Studio 2008 SP1
5. Expression Studio
   Hopefully you get this with your MSDN subscription, but if not you can get some love here.
6. Microsoft® Silverlight™ Tools for Visual Studio 2008 SP1
7. Microsoft Expression Blend™ 2 Service Pack 1
8. Deep Zoom Composer
9. The Silverlight Toolkit
10. ReSharper

Whew. Did I miss anything? The kitchen sink?

Getting a virtual machine connected to the outside world in Hyper-V is a non-intuitive process. I had to bumble around with it a bit before finding the secret combination that worked well. Before I show you how it’s done (or at least one way of doing it), here are a couple of things to keep in mind:

• When you add the Hyper-V role to Windows Server 2008, Hyper-V more or less takes over the physical computer and Windows Server 2008 becomes a virtual machine running in a special space called the home partition.
• Hyper-V uses the concept of virtual networks. It’s as if your computer magically ingested a Netgear network switch, you know, that little blue box with lots of blinking lights on one side and network cable plugs on the other, which you use to create a home computer network. That’s right, the brilliant folks at Microsoft figured out how to suck one of those network switched right into their server operating system (I’m not sure, but I think they’re using Wonkavision technology to do it). Not only is the network switch virtualized, but all the cables to connect to it are virtualized as well. Now that’s handy.
• Hyper-V implements three types of virtual networks: external, private and internal. An external virtual network gives virtual machines direct access to a physical network adapters on the physical computer. In effect, the virtual network shares the physical network adapter with the parent operating system (the Windows Server 2008 originally installed on the computer). A private network is used to connect two or more virtual machines running on the same physical computer to one another. An internal network is just like a private network, except it includes the parent operating system as well.
• A virtual machine connects to a virtual network through a Hyper-V network adapter. Yep, you guessed it – a Hyper-V network adapter is virtual as well. Each virtual network adapter can connect to only one virtual network. However, a virtual machine can have multiple virtual network adapters, with each adapter connected to a different virtual network.
• You can create any number of virtual networks and virtual network adapters in Hyper-V, limited only by how much load the hardware can support.
• You cannot create an external virtual network that connects to a wireless network adapter. Sorry, the folks who created Hyper-V simply decided not to go there. Fortunately there’s a simple workaround that I’ll show you in this post.

Let’s say you want to configure your virtual machine to automatically use the physical network adapter whenever it’s plugged into a live connection, and also use a wireless connection when the physical network adapter is not plugged in. Here’s how you do it:

Step 1. Setup your Virtual Networks

This procedure assumes that you are running Windows Server 2008 on a computer that supports hardware virtualization, and that you are logged into an account that is a member of the Administrators group.

• Launch the Hyper-V Manager

Create an Internal virtual network

• In the Actions menu, click on Virtual Network Manager
• In the box labeled “What type of virtual network do you want to create?” select Internal. Click the Add button.
• In the New Virtual Network dialog box, enter the following:
  - Name: Internal Virtual Network (wireless)
  - Connection type: Internal Only
  Click OK

Create an External virtual network

• Click on Virtual Network Manager
• In the box labeled “What type of virtual network do you want to create?” select Internal. Click the Add button.
• In the New Virtual Network dialog box, enter the following:
  - Name: External Virtual Network (wired)
  - Connection type: External
      Select the network adapter you want to use in the drop-down list
  Click OK
  
  The Virtual Network Manager should look something like this:
  
  
  

Step 2. Setup the Wireless Network Connection for Sharing

This step is the secret ingredient that allows a Hyper-V virtual machine to access a network connection through the physical computer's wireless adapter.

• Switch over to the parent operating system; i.e., the Windows Server 2008 originally installed on the physical computer.
• Launch the Network and Sharing Center
• Click on Manage Network Connections
  Note that there is a new network connection for each of the virtual networks you created in Step 3.
  
  
  
• Right-click on the Local Area Connection that shows “Internal Virtual Network (wireless)” below its name. Select Rename. Give it the name “Internal Virtual Network Connection”
• Right-click on the Local Area Connection that shows “External Virtual Network (wired)” below its name. Select Rename. Give it the name “External Virtual Network Connection”
• Right-click on your Wireless Network Connection and select Properties
• Click on the Sharing tab
• Select the checkbox labeled “Allow other network users to connect through this computer’s Internet connection”
  
  
  
  
• Click OK
  Your Network Connections list should now look something like this:
  
  
  

Step 3. Connect a Virtual Machine to the Virtual Networks

The procedure can only be performed on a virtual machine that is turned off. Do this for each virtual machine you want to connect to the external world.

• Switch to the Hyper-V Manager
• Select the virtual machine you want to configure.
• Click on the Settings link
• In the Hardware list, click on Network Adapter
• In the Network Adapter properties pane, select Internal Virtual Network (wireless). Click the Apply button
• In the Hardware list, click on Add New Hardware
• In the Add Hardware properties pane, select Network Adapter, then click the Add button
• Back in the Hardware List, click on the Network Adapter marked “Not Connected”
• In the Network Adapter properties pane, select External Virtual Network (wired). Click the Apply button.
  The Hardware list should now contain these two entries:
  
  
  
  
• Click OK to complete the configuration.

Step 4. Give it a Whirl

• Verify that the parent operating system has Internet connectivity
• Start the virtual machine
• In the virtual machine, log on, open a web browser and browse to your favorite web site.

Your virtual machine should now have total Internet connectivity!

I finally took the time to put together a chart showing which edition of Visual Studio needs to be installed on the Team Build server to achieve specific features. As you can see, Team Suite has you covered. As for the question of whether or not you need to purchase an additional copy of Visual Studio for this - that question has been answered on Jeff Beehler's blog as well as in the VSTS 2008 Licensing White Paper.

I might also add that Brian Randall mentioned that you can automate the validation of Architect Edition Deployment Diagrams on the Team Build server if you install that edition; but, being that he's the only guy on the planet to probably do that, I didn't think it was worth mentioning.

What?

Increasing Your Agility with Scrum and Visual Studio Team System

When?

12/12/2008
9:00 AM - 12:00 PM

Where?

Microsoft Corporation
401 West Front Street
Suite 400
Boise, ID 83702

Why?

Martin Danner, Richard Hundhausen, and I are teaming up to bring you a 4 hour introduction to Scrum and the supporting capabilities of Team System. This is a free event, open to the public, and is sponsored by Microsoft.

My hope is that we can provide value from 3 different perspectives.

1. Learn the basics of Scrum
2. Learn the basics of Team System
3. Learn how Team System can support Scrum teams

Sign up via the link above. I hope I see you there.

When looking at FinalBuilder and Team Foundation Build side by side, the obvious breakdown in features and advantages looks like this.

1. Team Foundation Build provides a complete build solution with easy integration to other components of Team Foundation Server and Visual Studio Team System. Here is a set of features that detail what integration really means.
   • Build reporting and archiving inside Team Foundation Server
   • Easy access to source control
   • Ability to quickly spool up quick and dirty builds
   • Simple scheduling tools providing day, time, and event driven build firing
   • Easy to use retention tools for "expiring" old build artifacts
   • Automated test execution
     
2. FinalBuilder provides an excellent visual development environment with pretty widgets to drop on a design surface. Creating build scripts visually can be a nicer design experience than working with the raw XML found in Team Foundation Build and tools like nAnt.
   
   Microsoft obviously recognizes the value of visual composition as the next version of Team Foundation Build (2010) is built on WF (Windows Workflow). This means builds tasks are effectively WF activities. If you've worked with WF, you may know that WF almost implies the next point: Team Foundation Build scripts will be built visually via a design surface in Visual Studio.
   
3. Arguably, the most significant advantage FinalBuilder has today is in the number of out-of-the-box build tasks (actions in FinalBuilder language) that come with the product. A complete list of FinalBuilder actions is available here.
   
   The complete list of FinalBuilder actions is exhaustive and I don't dare replicate it here.

Integration of the 2 Products

Regarding using Final Builder with Team Foundation Build, it is important to note that the two products don't preclude each other. Far from it, FinalBuilder ships with an integration task for working with Team Foundation Build. See this article for more information about using that integrated functionality.

This integration task gives us the ability to call FinalBuilder scripts from an automated (scheduled or event-fired) Team Foundation Build run. This is cool because we get the best of both tools:

1. TFB Gives us complete integration with the development platform and reporting tools of Team System.
2. 2. Final Builder gives us a nice visual development experience and more out-of-the-box build tasks than MSBuild.

Choosing the Right Tools from your Toolbox

One thing to keep in mind is this: Is the tool you need one that simply builds .NET web sites, class assemblies, and windows forms applications? If yes, the problem you are trying to solve is moderately simple. Team Foundation Build does a very good job of providing a complete solution for these scenarios.

FinalBuilder does have an additional expense associated with it, so if the build situation you are trying to solve is one of creating .NET binary packages, you may be better off using Team Foundation Build "unadorned". It does a great job of doing what it does.

If you are looking for other functionality like working with VB6 projects or spooling up virtual machines for deployment scenarios, FinalBuilder has a lot to offer. The promise of Team Foundation Build extending WF in the 2010 Team System release holds the promise of a solidly extensible build platform with an inherent visual design story. As Team Foundation Build matures, it will likely provide a feature parity competitor to FinalBuilder, but it has some catching up to do.

Microsoft has certainly been ratcheting up the community involvement over the last few years. In a down economy like this one, free training opportunities suddenly take on even more significance. Local user groups, Code Camps, product release events, and occasional "just because" events all provide opportunities to get together with local developers and maybe add a tool or two to your toolbox. One such initiative is the Fire Starter Event series.

These events are one day, free-to-attend, community produced deep-dive immersions on particular technologies. FireStarters are opportunities to learn about some technology in the MSFT stack that you may not be familiar with and would like to see the essentials needed to get started.

Think of FireStarters as mini Code Camps dedicated to specific technologies. Nice!

Currently scheduled FireStarters include:

• ASP.NET MVC in Pittsburgh, PA, Dec. 18th
• ASP.NET MVC in East Windsor, New Jersey, Dec. 13th
• Windows Development in Redmond, Dec. 12th. Attend this one via Live Meeting!
• Test Driven Development in Tampa, FL, Jan. 17th

Previous FireStarters have focused on Silverlight, ASP.Net + AJAX, and SQL Server. If you would like to see a FireStarter event in your community, contact your local MSFT Developer Evangelist and see what can be arranged.

If you exchange email with me on a regular basis, you know that I am the king of email faux pas. I regularly do things like this:

• Use CNTRL+Enter to send an email sooner than I really want to send it.
• Send emails that are missing attachments.
• Send from my work account when I meant to send from my personal account (this one is a biggy in Outlook).
• Hit Reply All when I meant Reply.
• Include the wrong person on the CC line.

In short, I am well aware of proper email etiquette, but I am notoriously bad at exercising it. All I really need is a last minute check to ensure I am not doing something stupid.

Enter my first real (Visual Studio Tools for Office) application. I just want to give myself an "Are You Sure" screen before sending an email in Outlook and review all the critical aspects of the email before I send it.

This Add In for Outlook 2007 simply displays a window before actually sending my email, giving me an opportunity to change my mind. It shows me the major things that I should check before really hitting send:

• The account I am sending the email from
• The addresses on the To: line
• The addresses on the CC: line
• The addresses on the BCC: line
• The number of attachments on the email.

The code is up on Elegant Code's Google Code SVN repo here and you can download the click once installer here. I guess if anyone cares about something as inane as this, you are welcome to send me feedback and suggestions.

I am the first to realize this is a lame little utility, but it was interesting to write it as I got a little more familiar with the VSTO model. Also, I know there aren't any real unit tests in the test project. The reasons for this are twofold.

1. The app is nothing much more than a Windows form with drag and drop attributes and 2-line event handlers.
2. I am feeling lazy tonight.

Enjoy.

Believe me, I understand TDD. I grok it. It is in my soul.

I also happen to believe (and know from experience) that unit test frameworks are valuable far beyond their use in TDD. Some of the best uses are for integration tests at the API level.

It is this coolness that makes it so handy to run a unit test harness as a load test run using VSTS. I worked with one client who had a particular need for this in testing a HUGE network of independently addressable embedded Linux devices, each one exposing a TCP/IP-level API. More on how to running unit tests as load tests here.

But on to my latest use of a unit test. Remember back in the day when we wrote libraries without unit test frameworks? What did we do? We wrote a little command line EXE to exercise the thing while we wrote it and never checked that in to SCC. It worked, mostly.

I often have the same need when writing Windows Forms applications. I want to spool up and play with a window without all of the overhead of the entire application. So, here's my test.

   1: namespace ElegantCode.BeSure.Test.GivenTheConfirmationDialogIsDisplayed

   2: {

   3:     [TestClass]

   4:     public class WhenTheUserClicksNo

   5:     {

   6:         [TestMethod]

   7:         public void ThenTheDialogResultShouldBeNo()

   8:         {

   9:             ConfirmationForm confirmationDialog = new ConfirmationForm();

  10:             DialogResult result = confirmationDialog.ShowDialog();

  11:  

  12:             Assert.AreEqual(result, DialogResult.No);

  13:         }

  14:     }

  15: }

No, this is not a unit test. All this does for me is allow me to open the window in a run time environment, see it lay out on the screen, click around on it, etc.

If you notice the structure of the test naming, I am using a little BDD convention because I am wondering about the idea of building a manual regression suite this way. What if a tester sites down and runs through a manual test by launching the a unit test harness that drives the UI.

It's an interesting idea, anyway.

Team_Build_Target_Map1.docx (22.73 KB)

I had the good fortune of reviewing the upcoming book titled Inside the Microsoft® Build Engine: Using MSBuild and Team Foundation Build. This book is an absolute must for anyone who is creating and customizing build definitions in Team Foundation Build. As part of my review process I created a map that lists the order of target invocation. I found this map very handy, so I’m posting it because I figure others will find it handy too. The map is listed below, and also contained in the attached word document. If you make any corrections or improvements to the map, please share back!

By the way, MSBuild Sidekick turned out to be very useful in building this map. The Team Foundation Build targets file is large and complex. MSBuild Sidekick's tree-view makes it much easier to navigate this beast, and the search features made it easy to traverse the target dependencies. This is a very handy tool for editing (or studying) build scripts.

This map shows the order of target execution in the Team Build targets file,  %ProgramFiles%\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets. The target names in the map are color coded as follows:

Green: this is an extensibility target that can be customized in your TFSBuild.proj file
Blue: This is run as a separate MSBuild process to support parallel processing

EndToEndIteration

When a Team Build agent starts a new build, the build starts by invoking the EndToEndIteration target. This target then invokes the following chain of targets.

·         CheckSettingsForEndToEndIteration

·         InitializeBuildProperties

·         BeforeEndToEndIteration

·         BuildNumberOverrideTarget

·         InitializeEndToEndIteration

·         InitializeWorkspace

o   BeforeInitializeWorkspace

o   CoreInitializeWorkspace

o   AfterInitializeWorkspace

·         TeamBuild

o   CleanAll (CleanCompilationOutputOnly != true)

o   InitializeBuild

o   PreBuild

§  Get

·         BeforeGet

·         CoreGet (SkipGet != true)

·         AfterGet

§  Label

·         BeforeLabel

·         CoreLabel (SkipLabel != true)

·         AfterLabel

o   CleanCompilationOutput (CleanCompilationOutputOnly == true)

§  BeforeClean

§   CallClean (SkipClean != true)

·         CoreCleanCompilationOutput

o   ComputeConfigurationList

o   CleanConfiguration

§  BeforeCleanConfiguration

§  CoreCleanConfiguration

·         ComputeSolutionList

·         CleanSolution

§  AfterCleanConfiguration

§   AfterClean

o   Compile

§  BeforeCompile

§  CallCompile

·         CoreCompile

o   CompileConfiguration

§  BeforeCompileConfiguration

§   CoreCompileConfiguration

·         ComputeSolutionList

·         CompileSolution

o   BeforeCompileSolution

o    CoreCompileSolution

o    AfterCompileSolution

§   AfterCompileConfiguration

§   AfterCompile

o   PostBuild (SkipPostBuild != true)

§  GetChangesetsAndUpdateWorkItems

·         BeforeGetChangesetsAndUpdateWorkItems

·          CoreGetChangesetsAndUpdateWorkItems (SkipGetChangesetsAndUpdateWorkItems != true)

·          AfterGetChangesetsAndUpdateWorkItems

o   Test

§  BeforeTest

§   CoreTest

·         RunTest

o   TestConfiguration

§  BeforeTestConfiguration

§   CoreTestConfiguration

·         ResolveTestFilesForEndToEndIteration

§   AfterTestConfiguration

§   AfterTest

o   GenerateDocumentation

o   PackageBinaries

·         DropBuild

o   BeforeDropBuild

o    CoreDropBuild (SkipDropBuild != true)

o    AfterDropBuild

·         AfterEndToEndIteration

DesktopBuild

This is the target execution sequence when you perform a Desktop Build. For more information on configuring and using a Destop Build, see this MSDN article.

·         Compile

o   BeforeCompile

o   CallCompile

§  CoreCompile

·         CompileConfiguration

o   BeforeCompileConfiguration

o    CoreCompileConfiguration

§  ComputeSolutionList

§  CompileSolution

·         BeforeCompileSolution

·          CoreCompileSolution

·          AfterCompileSolution

o    AfterCompileConfiguration

o    AfterCompile

·          Test

o   BeforeTest

o    CoreTest

§  RunTest

·         TestConfiguration

o   BeforeTestConfiguration

o    CoreTestConfiguration

o   AfterTestConfiguration

o    AfterTest

·          GenerateDocumentation

·          PackageBinaries

DesktopRebuild

Start a build using DesktopRebuild as the initial target to perform a clean, full compilation and run tests.  For more information on how to build team projects on the desktop, see this MSDN article.

·         Clean

o   BeforeClean

o   CoreClean

·         CoreCleanAll (CleanCompilationOutput != true AND SkipClean != true)

·         CallClean (CleanCompilationOutput == true AND SkipClean != true)

o   CoreCleanCompilationOutput

§  ComputeConfigurationList

§  CleanConfiguration

·         BeforeCleanConfiguration

·         CoreCleanConfiguration

o   ComputeSolutionList

o   CleanSolution

·         AfterCleanConfiguration

o   AfterClean

·         DesktopRebuild (see previous section for details)

OnBuildBreak

If an error occurs during the compile phase, normal processing is suspended and the OnBuildBreak target is invoked. This target then invokes the following sequence of targets:

·         BeforeOnBuildBreak

·          CoreOnBuildBreak

o   GetChangesetsOnBuildBreak

§  BeforeGetChangesetsOnBuildBreak

§   CoreGetChangesetsOnBuildBreak (SkipGetChangesetsAndUpdateWorkItems != true)

§   AfterGetChangesetsOnBuildBreak

o   DropBuild

§  BeforeDropBuild

§   CoreDropBuild

§   AfterDropBuild

o   CreateWorkItem

§  BeforeCreateWorkItem

§  CoreCreateWorkItem (SkipWorkItemCreation != true)

§  AfterCreateWorkItem

·         AfterOnBuildBreak

Skip Properties

These properties are used to suppress the execution of certain targets in the build sequence.  A complete list of customizable Team Foundation Build properties can be found in this MSDN article.

·         SkipClean

·         SkipDropBuild

·         SkipGet

·         SkipGetChangesetsAndUpdateWorkItems

·         SkipInitializeWorkspace

·         SkipInvalidConfigurations

·         SkipLabel

·         SkipPostBuild

·         SkipWorkItemCreation