Changing the default Virtual Directory/[TARGETVDIR] name in a Visual Studio Setup Project

While working on a Visual Studio Setup Project for an ASP.NET MVC application, I ran into an interesting dilemma. The installer automatically uses the Title of your setup project as the default virtual directory value. From a user experience standpoint, it can serve as a visual indicator that this "virtual directory" is specifically for the application that you (the user) are installing.

However, it isn’t ideal. See, usually the title of an installer is human readable e.g. "My Application". However, I don’t think user would want their virtual directory to contain spaces since spaces typically get escaped to a hex value, making your site’s address http://someserver/My%20Application. Visual Studio Setup Projects do not offer a straight-forward way of editing this default value, except to edit your title to read "MyApplication".

There are a handful of solutions that have been conceived by various people that include passing command line arguments or using custom dialog windows that set the TARGETVDIR parameter explicitly – to name a couple.

For different reasons, none of the proposed solutions satisfied my dilemma.

So, here is what I did:

I opened the deployment project in notepad++ (a very handy text editor), found the line that says, "VirtualDirectory" = "My Application" and changed it to "VirtualDirectory" = "MyApplication". After saving the file, reloading it in Visual Studio, and building my installers, my dilemma was solved. I hope this is helpful to you as well.

Gestalt = Low-Lying Awesome

Microsoft appears to be betting big on Silverlight.  When the Silverlight 1.0 bits were released in 2007, my initial thoughts were, “Yay, Flash for .NET developers.”  As Microsoft pushed forward with version 2, version 3, and now version 4 of Silverlight, those sarcastic thoughts have subsided to make way for more genuine curiosity.  How did that happen?

Well, for starters, Microsoft delivered real features.  Initially, Silverlight demos were all about media (music and video).  In addition, Microsoft touted the interopability between dynamic languages like vbx, c#, python, ruby, and javascript.  Then, that interopability was sidelined and Silverlight applications started to emerge.  Which was interesting.  In fact, Silverlight 2 had enough features to stir up debates in the enterprise over which RIA technology was best suited for enterprise applications: Flash 8 with Flex or Silverlight 2.   Then, Microsoft played their wildcard.  They made Silverlight play nicely with … ugh … Mac OSX.  Out-of-browser Silverlight applications made me raise my eyebrows for a technology that I had quickly written off as a “fad”.

That might still be the case.  I won’t make a claim either way.  But, Silverlight and RIA are spaces where Microsoft continue to innovate.  Gestalt is a very good example of that last statement.  Gestalt is built atop a foundation consisting of XAML, Silverlight, and dynamic languages.  It enables web developers to script their way to rich internet applications in a way that both Flash and Silverlight seemingly missed. 

With that said, it is difficult to pinpoint exactly what value Gestalt adds, but you feel it when you’re molding some python, ruby, or javascript hackery into a magical Silverlight-powered application that just works.

The technology appears to still be more of a proof-of-concept than a supported product.  But, it makes a strong case for embracing XAML and Silverlight. 

Checkout the website and the samples at http://visitmix.com/labs/gestalt/.