Using StudioShell to generate WiX XML

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.

PowerShell The Community’s Command Line Part 27 of 31: It Takes a Community to Raise a Language

Much like the saying It takes a village to raise a child, it takes a community to raise a programming language. Without passionate people in that community, the word won’t spread and a language can die. Yesterday, I talked about some of the cool community resources and sites. Today, I want to salute those who are working on community projects with PowerShell. These are just a few of the many out there.

StudioShell, by Jim Christopher (@beefarino)

http://studioshell.codeplex.com/
StudioShell is an integrated PowerShell host available inside Visual Studio 2010 and 2008. This tool exposes Visual Studio’s extensibility points and makes it easier to extend your Visual Studio from the command line rather than from compiled binaries. Jim will be giving a presentation on his StudioShell project and using it to extend Visual Studio at CodeStock 2011 down in Knoxville, TN this June.

MongoDB PowerShell Provider, by Jim Christopher

http://mosh.codeplex.com/
If you’re in an environment where you need to manage a Mongo database, then the MongoDB PowerShell Provider may make your life a little easier in managing the database from within PowerShell. This project is nicely documented both on the CodePlex site and from within PowerShell.

PowerShell Script Provider, by Oisin Grehan (@oising)

http://psprovider.codeplex.com/
While developers who can think out a provider’s logic may be more comfortable with writing the provider in C#, this provider allows IT Pros and those comfortable with PowerShell to write their providers in the PowerShell scripting language. Oisin Grehan, PowerShell MVP and PowerShell provider guru, is the guy behind this project. It’s great to see the option of writing providers in PowerShell, as working with the scripting technology directly in its own language makes more sense to many scripters.

Show-UI: The PowerShell WPF Toolkit

Show-UI
For those who have our book, disregard the recommendations on page 397 on the two things to help with WPF apps in PowerShell, as WPK and PowerBoots are merging. Show-UI is the project that they are merging into. Yes, you can use PowerShell to create GUIs. Show-UI is a project that can help make that process even easier in PowerShell. Shoutouts to the coordinators and developers – Jaykul, Doug Finke, and James Brundage.

Others?

Got any other PowerShell projects that you want to share? Leave me a comment!