Configuring Virtual PCs' network adapters can be confusing.  If you think about it, you're taking a network card, which typically has one IP address and one MAC address, and making it work for two computers.  Add to that security issues - you may not always want a virtual pc getting out over your network- and things get complex quickly.   Recently, though, I wanted to set up a SharePoint demo on a virtual machine, and wanted a setup that:

• Allowed my host pc to connect to the web server on the virtual pc.
• Allowed the virtual pc to connect to the internet.
• Allowed the virtual pc to connect to my host pc

After a little digging, I came across this post on Ben Armstrong's blog that spelled out how to install the 'Microsoft Loopback Adapter' and wire it up to a host network adapter.  It worked as advertised, but I had to reboot and forgot to set the loopback adapter in the virtual machine network settings.   In retrospect, both pretty obvious steps, but, for posterity, here are full instructions for the above scenario (Most of these are straight from his post - be sure to check his blog out for much more Virtual PC info):

Install Microsoft Loopback Adapter:

• On the host operating system go to 'Control Panel'
• Go to 'Add Hardware'
• In the 'Add Hardware' wizard, click 'Next'
• When the 'Is the hardware connected?' page appears, select 'Yes, I have already connected the hardware', and then click 'Next'
• In the 'Installed hardware' list, select 'Add a new hardware device' and then click 'Next'
• In the 'What do you want the wizard to do?' list, select 'Install the hardware that I manually select from a list (Advanced)', and then click 'Next'
• In the 'Common hardware types' list, click 'Network adapters', and then click 'Next'
• In 'Manufacturer' list, select 'Microsoft'
• In the 'Network Adapter' list, select 'Microsoft Loopback Adapter', and then click 'Next' twice
• In the 'Completing the Add Hardware Wizard' page, click 'Finish'

Turn Internet Connection Sharing on, on the adapter that you want to share, NOT on the loopback adapter.  Typically this is your Wifi or LAN adapter.

• On the host operating system go to 'Control Panel'
• Go to 'Network Connections'
• Right click on the network connection that you use for Internet connectivity and select 'Properties' 
• Click on the 'Advanced' tab
• Check the option to 'Allow other network users to connect through this computer's Internet connection'
• If you have multiple network adapters you will need to also specify that you are sharing the Internet connection with the Microsoft Loopback Adapter.
• Click 'OK'

At this point, I had to reboot.  Your mileage may vary.

Finally, in the virtual machine's settings, change the network adapter to use the loopback adapter:

• In Virtual PC, go to Settings -> Networking for the machine
• Set Adapter 1 to 'Microsoft Loopback Adapter'
• Click 'OK'

I got my beta invite today and tried out Windows Live Mesh.   There a are a couple similar services out there, not the least of which is Microsoft's own FolderShare.  But what makes Mesh interesting is the promise of true, seamless synchronization between PCs, mobile devices, and the web.  Your data just appears everywhere you want it to.  In theory, there's no need to use ActiveSync or any other tool to sync up.  Add to that a sharp, clean UI and this is an interesting new product (Excuse me, Technology Preview).

By sheer coincidence, I also played with Peer-to-Peer binding in Windows Communication Framework.  This lets you very easily expose your services in a P2P manner, and also uses the term "mesh" to describe the "cloud" into which your application is connecting.  I haven't quite figured out when I could use it in a typical line-of-business app, but there's something fun about being able to dress up your services in P2P, Message Queuing, or any of the other suits WCF offers, just by adjusting configuration.

Did you know there was a "hidden" code-generation feature in VS2008?  Text Templating Transformation Toolkit  (aka T4) actually debuted in VS2005 Guidance Automation Toolkit, but shipped baked into VS2008.  This gives you CodeSmith-style code-generation templates that can be used in your projects to generate code from any source.  Simply add a text file with the extension ".tt", and VS will add a "Transform Templates" button to the solution explorer window. 

Here's a video that shows some of the basics:
http://msdn2.microsoft.com/en-us/vs2008/cc308634.aspx

There are all sorts of jokes that could be made about this, but this is a really cool extension of the Surface concept to things like medical charts, wallets, and prescriptions.  I just hope they can bring these ideas to market soon!

VS 2008 has what I think is a very annoying bug and Redmond thinks is a useful feature.  If you create multiple web applications within a single solution, then when you run the solution, by default VS will launch a "Cassini" WebServer for each web application project.  The rational Microsoft gives for this being a "by design" feature is that you may want this behavior when, say, debugging a web app that connects to a separate web-hosted WCF service.  Sounds reasonable, except there already exists functionality just for this purpose: Solution -> Properties -> Multiple Startup Projects!  If I check "Single startup project" here, then under no circumstances should multiple projects start up!  This is especially annoying when developing solutions with several web projects - each spins up a little web server icon in the task tray, with an annoying "pop" and balloon telling you where it's running.  In addition, each takes up memory and slows down the build-and-run.

I scoured Google and the forums and got nothing on this, but this afternoon I happened on the simple workaround.  With a solution explorer and properties window open, select each web application project.  In the properties tab, set "Always Start When Debugging" to false.  Next time you run, only the projects specified in Startup Projects will be run!  Note that this "properties window" is NOT the same as the "Project Properties" that you get to from Project -> Properties.

Microsoft at Mix08 announced today some very cool new bits:

• Silverlight for Windows Mobile and Nokia S60
• Silverlight 2.0 for Windows and OSX
• Internet Explorer 8 Beta 1
• ASP.NET MVC Preview 2

All fun stuff to poke around with!  Also, at another conference, they announced .NET Micro Framework v2.5, which now supports TCP\IP and web services.

We've been having some weirdness going on with our source control.  Nothing major- (Note to our clients: your code is safe and backed up daily!) - but little things like files getting out of sync, or appearing checked in in the IDE, but not in the source control server.   While searching about it, I ran across this definitive guide to source control  by none less than Mr. Source Control himself, Eric Sink- founder of SourceGear.   This mini e-book is very well-written and covers a broad spectrum of source control concepts and tools - not just Vault.  In addition to explaining the concepts in laymen's terms, he peppers best practice side-bars through out the text, distilling the concepts into concrete guidance developers can use.   It's old - started in Aug 2004- so I'm surprised I'm just now coming across this, but it's definitely a must-read for any developer working in a team > 1.

I've been experimenting with the idea of using System.Reflection.Emit to generate code from interfaces.  If you're not familiar with this namespace, it contains classes to generate compiled assemblies programmatically.   Regex uses this when compiling a regular expression for faster execution.  Instead of parsing the expression each time, it generates on-the-fly a class that can be used to execute the expression.  This namespace is also used by Mock Type frameworks such as RhinoMocks and TypeMock.  Given a base class or interface, these generate on-the-fly a class that can mimic the base enough to use when unit testing.  I'm sure there are other places this is used, but suffice it to say this is one of those obscure corners of the framework that us Morts rarely dig into.  So it's not surprising that I would run into an obscure error that stumped even Google.

I religiously studied the MSDN examples and wrote code to let me do something like this:

ICustomer concreteType = CodeGenerator<ICustomer>.GetInstance();

You can see how freaking awesome this could be for component development- I get, at runtime, a class that implements my interface, but I don't have to wire up goo like INotifyPropertyChanged, IDataError, property getter/setters, etc.   Depending on how my tinkering goes, more on the awesomeness later.  The error I was getting whenever I called typeBuilder.CreateType() was:

System.TypeLoadException: Method 'get_Id' in type 'Customer' from assembly 'TypeAssembly, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' does not have an implementation

Except I WAS implementing 'get_Id'.  I copied the code to do it straight from MSDN! See:

MethodAttributes getSetAttributes = MethodAttributes.Public |
MethodAttributes.SpecialName |
MethodAttributes.HideBySig;
var getMethodBuilder = typeBuilder.DefineMethod("get_" + propertyOnInterface.Name,
                                                getSetAttributes,
                                               propertyOnInterface.PropertyType,
                                               Type.EmptyTypes);

ILGenerator getMethodIl = getMethodBuilder.GetILGenerator();
getMethodIl.Emit(OpCodes.Ldarg_0);
getMethodIl.Emit(OpCodes.Ldfld, fieldBuilder);
getMethodIl.Emit(OpCodes.Ret);

propBuilder.SetGetMethod(getMethodBuilder);

Much googling turned up only a few unrelated posts.  After testing, I discovered that removing a call to 'AddInterfaceImplementation' fixed the issue- though the resulting class no longer implemented my interface.  Clearly the interface was generating some sort of code.  Some more digging, and I figured out the solution:

MethodAttributes getSetAttributes = MethodAttributes.Public |
MethodAttributes.SpecialName |
MethodAttributes.HideBySig;| MethodAttributes.Virtual;

I could be flawed in my understanding here, but apparently, when adding an interface, .NET treats property get and set accessors sort of like abstract methods.  The code I was generating did implement 'get_Id', but did not mark it as overriding the interface's definition.  So, when creating the type, there was the interfaces' unfinished implementation of 'get_Id', and my completely unrelated 'get_Id'. 

So anyway, hopefully this post will make it into Google and help some other poor guy who, late one night, finds themselves turning over parts of the framework better left alone.

Here's a fun Alt-Tab Shortcut that lets you switch apps without leaving the comfort of your mouse.  Just download, place in Startup, and run.  When it's running, you can switch apps by holding down the left mouse button and clicking the right.   Like most productivity apps, I may find myself forgetting it's there and not using it after the novelty wears off, but I guess we'll see.

Incidentally, the standalone exe is a feature of AutoHotKeys, which is one of those said productivity apps that I forget about and rarely use.  The idea is pretty neat though. It's a little scripting language for automating those little repetitive tasks that we all hate.  The end result is apparently a standalone exe that "just works", no installer required.

One of the challenges of being a contract software developer is that we often work remotely on a clients' network via VPN.  Each client has their own VPN client, Source Control, and development environments.  In many cases, development platforms just aren't made with this in mind.  It's only as of VS 2005 that you can even switch Source Control Providers easily! If you've ever had to connect to Microsoft SourceSafe over VPN, you know it's still not designed with remote work in mind.  It relies on a network file share, which can be problematic over VPN.  It does ship with a WebService based solution, but this may not be feasible for the client to install in all cases.

The Problem

When connecting over VPN, the main problem is that there is no option to specify the network user to connect with.  For example, you may log in to the clients' VPN, but still attempt to access resources using your machine's local account.  When doing things like mapping drives, it's easy to supply an alternate username and password.  However, with SourceSafe, there is no option to supply network credentials when connecting (which are totally different from the SourceSafe credentials).

The Solution

Enter the Windows runas command.  This command lets you run any application as though it were a different user.  In this case, you want to run Visual Studio as though you were that network user.  To set this up:

• Create an empty text file named "RunVisualStudioAs[DomainUserName].bat"
• Edit and Add the following:
• runas /netonly /user:[Domain]\[User] "C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe"
• Save.

Then, when working on the project, just launch VS using the batch file.  You will be prompted for a password each time, since runas does not allow entering a password in the commandline for obvious security reasons.  But there are 3rd party runas replacements which can help you get around this.

One other word of caution:  Due to the chatty nature of Windows file sharing, this will still be very slow over a remote connection.  Turning off Anti-Virus helps a little, and there are some additional speed tips here. It's definitely not the ideal solution, but it can be done!