I have to say it – after seeing Jim Christopher‘s StudioShell talk at devLink this past year, I think it’s been my most favorite Visual Studio tool so far.  I get to use my PowerShell knowledge to help script stuff out, saving my teammates a ton of work.  Today, we added about 10 new pages to one of our client’s sites and had to update a WiX installer.  Recognizing patterns and an opportunity for PowerShell, I just had to use StudioShell to eliminate the tediousness of generating the XML code manually.

Background

We have a Visual Studio 2010 solution with numerous projects – class libraries, WiX installers, and at least one web application.  One of the annoyances we have on our team is maintaining the WiX files every time we update a page, in order to make sure our pages get deployed properly.  So imagine our frustration today, after adding about 10 pages of content to our web application, we realized that we had to update our WiX installer for the website.

For those not familiar with WiX – Windows Installer XML (WiX) is what’s used in creating MSI files from XML.  You can use the WiX toolset to help you maintain these packages.  The WiX toolset documentation is available on SourceForge.  Every time we need to add a file to the server, we have to update our WiX wxs file.  Syntax for that looks something like this:

<File Id="SampleFile.aspx" Name="SampleFile.aspx" Source="$(var.OurSamplePath)SubfolderSampleFile.aspx" />

Problem and Solution

Our problem was that we needed to create that line for 10 new ASPX files.  Sure, we could have borrowed a line from one of the files already in the directory, copied and pasted it 10 times, and then manally search-and-replaced each of these instances.  But even that takes a long time.  Knowing what I did with what tools I had available, this is how I saw it.  That XML above pretty much boiled down to this for me:

<File Id="{0}" Name="{0}" Source="$(var.OurSamplePath)Subfolder{0}" />

I saw that pattern and realized I could turn that into a string and pass it the names of the files.  I also realized that I could use StudioShell to navigate through my project’s structure to get a list of the new files – which happened to be all of the ASPX files in a particular director and output them into this XML.  My StudioShell commands looked something like this:

cd DTE:
cd solutionprojectsProjectNameSomeSubFolder
dir *.aspx | % { "<File Id=`"{0}`" Name=`"{0}`" Source=`"`$(var.OurSamplePath)Subfolder{0}`" />" -f $_.Name }

The StudioShell output looked something like this:

<File Id="AgeGroups.aspx" Name="AgeGroups.aspx"
Source="$(var.OurSamplePath)SubfolderAgeGroups.aspx" />
<File Id="Fees.aspx" Name="Fees.aspx"
Source="$(var.OurSamplePath)SubfolderFees.aspx" />
<File Id="Home.aspx" Name="Home.aspx"
Source="$(var.OurSamplePath)SubfolderHome.aspx" />

What took me a few minutes to type the command, run, copy the output, and paste into the wxs file could have easily taken longer if I hadn’t had StudioShell.

Note: While I could have fired up PowerShell and navigated my code via the FileSystem provider (as the dir command and the string formatting are PowerShell), I preferred to use StudioShell because our projects in the solution were in different folders and having the DTE:solutionprojects navigation that StudioShell made it that much more easier and convenient to just do this work from within Visual Studio.

Conclusion

Once again, having StudioShell as part of my installed Visual Studio tools made it that much easier for me to script out a process and get the results I needed within a much shorter period of time than doing it manually.  If you haven’t checked out StudioShell yet, you can find it at http://studioshell.codeplex.com.