PhatBoyG.com

This past week I setup a new development environment on my MacBook Pro. As I got into it, I realized that it might be a good idea to share the setup process with others who might be switching to a Mac. Unlike a lot of people that use Windows XP for development, I do all my .NET development on Windows Server 2003. I have always had a firm belief in developing on your target environment.

For this discussion, I will be using VMware Fusion to run Windows. I’ve always been a fan of VMware, and their Mac OS X version continues to impress. There are many slick features in VMware Fusion, including Unity mode and dual-processor support. I’m going to be installing on my MacBook Pro, which is a 2.4 GHz Core 2 Duo with 4 GB of RAM (using the Santa Rosa platform, for full 64-bit memory support). I’m going to install the 32-bit version of Windows Server 2003 since the tools are all 32-bit applications.

I highly recommend getting your installation disks as ISO files (from MSDN, of course). VMware can mount the disk images directly, and they load a lot faster than using the physical media. For the purpose of this installation, you’ll need the following disk images:

• Windows 2003 Server R2 with Service Pack 2 (disk 1, 2 is not needed)
• Visual Studio 2005 Professional
• Microsoft MSDN Library for Visual Studio 2005 (optional)
• Microsoft SQL Server 2005 Developer Edition

You’ll also need the following downloads:

• Visual Studio 2005 Service Pack 1
• Windows 2003 Server Hot Fix for large installer files
• SQL Server 2005 Service Pack 2

Creating the Virtual Machine

To create your virtual machine, start up VMware. On the Virtual Machine Library window, select New. On the New Virtual Machine Assistant, click Continue. For Operating System, choose Microsoft Windows, for version, choose Windows Server 2003 Standard Edition. When choosing a name for your VM, I find it helps to pick something that reflects what development will be done. I have two, one called W2K3×2K5 and one called W2K3×2K8. As you might guess, the first has Visual Studio 2005 and the latter has Visual Studio 2008.

When choosing a disk size, be sure to give yourself enough room for your tools and applications, but don’t go overboard. Before I rebuilt my VMs, none of them were over 14GB in size so I chose a size that would give a little room to grow. Now, you could pick something like 40GB and configure the VM to grow the disk file as space is consumed but I prefer to allocate the entire disk in 2GB chunks at creation to get the best performance. I don’t usually use a lot of local space since all of my source code is kept in a remote Subversion repository.

The next screen is the Windows Easy Install. This is an easy way to get the operating system setup without any user intervention. Just make sure your install disk ISO is ready, and enter your name, password, and Windows key. Check the “Make your home folder accessible to the virtual machine” so that you can easily transfer data from OS X to Windows. I make the folder read only, since I don’t trust Windows to write to my home folder. Once the Finish screen displays, uncheck the Start and Install now option since we want to make some tweaks before the OS install begins. You can go ahead and pick your ISO for the installation.

Once the VM has been created, go back to the Virtual Machine Library, pick your virtual machine, and click Settings. We need to tweak a few things before we let Windows install.

• Battery - I let the guest see the battery status
• Display - Uncheck since we are not using XP
• Memory - I give the VM 1492 MB, but you can adjust to taste.
• Processors - Two (2) virtual processors should be set for installation.
• Network - NAT or Bridged are the only real options here. NAT is good when you don’t need other machines to have access to the VM, but use Bridged if you want a direct link to the network. If you use NAT, you can get to your Mac from the VM using the .host name.
• Sound - I like sound, I enable it.
• Shared Folders - This should be fine based on how the VM was created.
• USB - I like to be able to use my flash drive in the VM, so I enable this option.

Once the settings are tweaked, go ahead and fire up the VM. Windows should install without any user intervention and after a short time (the install runs super fast from the ISO) you should have a working Windows Server 2003 installation. Once you have it up and you are logged in, it’s time to run Windows Update to get all the latest patches (there will be a ton of them). Go ahead and let them install, and be sure to get the optional .NET 2.0 and .NET 3.0 packages as well.

Now that we have Windows setup, it’s time to take away all the things we don’t need.

• Disable automatic updates — we can do that when we need to do it.
• Disable remote access into the machine (no Remote Desktop or Remote Assistance).
• My Computer, Properties, Advanced, select Adjust for Best Performance for Memory and CPU.
• Set virtual memory to a fixed size of 1GB.
• Advanced Startup and Recovery - Uncheck all reporting and set Debugging Information to none.
• Disable error reporting and turn off critical error notification

In the control panel, we need to tweak a few things as well:

• Set your time zone and turn off automatic time synchronization.
• Turn off the screen saver, set the background to none, and make sure Windows Classic is selected for the theme.

In the registry, this tweak really decreases disk access in your VM:

• HKLM\System\CurrentControlSet\Control\FileSystem
  Add a new DWORD named NtfsDisableLastAccessUpdate and set it to 1.

I also disable the following services:

• Automatic Updates
• Error Reporting Service
• Help and Support
• Windows Time
• Wireless Configuration

Remove the following files:

• All the $whatever$ directories in C:\Windows except for the $hf_mig$ directory.

Add Operating System Components

• Use Add/Remove Programs, and select the Add/Remove Windows Components option.
• Add IIS (including ASP.NET support)
• Add Message Queueing (if you plan to use it)
• Remove Enhanced Internet Explorer Security
• Install any extra fonts you use for development, such a Consolas.

It’s probably a good idea to run Windows Update again after adding these features since they’ve likely been patched.

Back Up Your New VM

Now that we have a nice clean system, I recommend you shut down the VM and make a backup copy. Simple copy the Documents/Virtual Machines/YourVMName to an external drive so you can easily create new VMs without doing the Windows install again. If you do so, I recommend using SysPrep to reseal the operating system so all new SIDs are created. Do not make a backup for the purpose of closing after installing SQL Server 2005 since it goes crazy if you change the machine name after it is installed.

Software Installation

I recommend installing Visual Studio 2005, followed by SQL Server 2005. For Visual Studio, if you aren’t going to do any Smart Device programming, I highly recommend you uncheck all those packages from the installer. I would also choose not to install Visual J# for obvious reasons. Once the install is complete, be sure to run it at least once. Then install SQL Server 2005 (running as Local System when asked). If you don’t care about SQL 2000 support, don’t bother with the compatibility sort orders and just pick Latin from the top. Once both are installed, go ahead and install VS2005 Service Pack 1 and SQL Server 2005 Service Pack 2.

At this point, you have a pretty basic system with the needed applications. If you’re going to do any work on open source projects, you will need Subversion, TortoiseSVN, and NAnt. Many recommend VisualSVN, but I have never used it so I can’t comment but I’ve heard good things. When downloading applications to install, I recommend pulling them down using Safari into your Downloads folder. Then in your VM, go to the “on my Mac” share and run the installers from your shared folder. I never download anything inside the VM unless I absolutely know it can be trusted (which is pretty much never).

You will notice that I didn’t install any “fearware” such as virus or spyware tools. That’s my style, I don’t really care to slow down my system with things of that nature. I maintain a tight VM and rarely introduce anything from the outside so it’s my choice. Your mileage may vary.

And before I write another word, you should install Resharper and start on your path to becoming a Resharper Jedi.

Wrap Up

I hope this post has been helpful for those looking to setup a development VM. I’ve found that using Leopard OS X for everything but development to be a pleasure compared to the applications available for Windows.

It seems the MVC (model-view-controller) framework being added to ASP.NET has been released as a CTP.

There are a ton of posts about how to use the MVC, including a great series on Scott Gu’s Blog.

There, now I’m one of the thousands who probably blogged this today.

This weekend I will be giving a presentation on MonoRail at the second annual Tulsa TechFest. The event is packed with technical information for anyone in IT including a variety of tracks on security, networking, software development and management.

Last year I talked about using Microsoft’s new ASP.NET AJAX (previously Atlas) tools for building browser-based applications, as well as how to leverage the tools with asynchronous web services. This year I’ve chosen to present a getting started level introduction to MonoRail. With the Microsoft announcement of an MVC framework (System.Web.Mvc), it’s no doubt that there will be a lot of interest in what MVC is and how it differs from regular WebForms development.

The excerpt for my talk reads:

MonoRail is a different way to build ASP.NET applications that enforces the separation of concerns. Built using the model-view-controller (MVC) pattern, MonoRail uses controllers to handle application flow, models to represent data, and views for presentation. The end result is a web application that is maintainable and testable. This session demonstrates how to get started using MonoRail quickly and easily.

If you are anywhere near Tulsa, I highly recommend attending the free event this weekend. There will be a ton of technical content, free lunch, giveaways, and a whole lot of nerds. If you are shopping for a job, I can absolutely guarantee that there will be several consulting firms looking for developers to fill out their staff.

Imagine a system with a large amount of C++ and Classic ASP code. The ASP code handles the presentation of data only, making calls into C++ COM objects when data or logic functions are required. In order to take advantage of the huge productivity gains, new code is written in C# and .NET 2.0 when possible.

One of the challenges in adding .NET code to an existing C++/COM application is calling infrastructure components from the new .NET code. Interop can be used, however, this can drastically impact the design of the new code by forcing coding decisions to match outdated idioms. By replacing the old code with new .NET bits, the model and services built in .NET can be more appropriately structured using solid design methods (DDD is my preferred choice in this area).

At ALT.NET, we had a conversation about testing legacy code. The quick response was, “Read Feathers.” The book, Working Effectively with Legacy Code covers a lot of integration topics about legacy code, particularly C++. I plan to pick up a copy in the near future. But the discussion continued and I made a few realizations on how to approach the problem of migrating legacy code to .NET.

When examining a legacy component, don’t focus on the methods in the interface. With a Test-Driven Development approach, the client comes first. Therefore, the new .NET project is written to the point where the legacy dependency is needed. Once a dependency is identified, create tests to call a new interface providing the services of the legacy component. Once the interface methods are defined (from the viewpoint of the caller, not the legacy component), create a proxy class that implements the new interface but using the existing COM component for the implementation.

At this point a new interface, proxy class, and set of tests that exercise the methods have been created. Using the newly created tests, verify that the new interface works as designed. For systems that need to retain the legacy code for other application purposes, the work is done. There is no duplication of code and the new projects are not limited by the design of the legacy components.

However, if the goal is to replace the legacy component, the tests can be used to validate a new implementation. Build a new class in C# and implement the new interface in .NET code. The tests created for the proxy class can be used to verify the implementation in the new class. Once the dependencies on the legacy component are eliminated, the legacy component itself can be removed. If the dependencies on the legacy code cannot be removed, reconsider the decision to duplicate the implementation.

In some cases, it may be desirable to replace a legacy interface with the new implementation. While it is possible to create a class in .NET that implements an IDL-defined interface, there are some gotchas that need to be addressed.

An app.config file will need to exist for every application that used the legacy component. In the case of an ASP application, this means an inetinfo.exe.config or w3wp.exe file we need to exist in the inetsrv folder under /windows/system32. This can result in problems where the server is being shared with other ASP applications.

The new assemblies will need to be registered with regasm using the /codebase parameter. This means the assembly and all of the dependent assemblies will need to be strong named. By registering the assembly with this method, the assembly does not have to be installed in the GAC (which is pure evil IMHO).

The new class must have a ComDefaultInterface attribute and must not have a ClassInterfaceType attribute. The IDL-defined interface dictates the type (dual/custom) of calls supported.

I have personally used this method to transition code from legacy ASP/COM to ASP.NET and C#. It would be wise to note that legacy interop is not easy and it is not perfect. There are a number of gotchas along the way. My only other recommendation is to test early, test often, and stick to implementing only what the client (calling application) needs to function.