Quick setup reverse engineering lesson - finding direct links to VS 2005 Express Edition beta 2 packages

I got a question from a customer asking for direct download locations for each of the VS 2005 Express Edition beta 2 packages. I replied to that customer with a blog post previously posted by a colleague of mine here. But as I thought about this question more, I realized that it is probably possible to figure out this information from the publicly available setup packages for the Express Edition beta 2 versions with a little bit of ingenuity and knowledge of setup technologies. So I decided to try to figure out the download locations myself without using any Microsoft internal web sites or discussion aliases as part of my data gathering.

Here is how I proceeded:

  1. Download the setup package for one of the VS 2005 Express Edition beta 2 packages - I randomly choose C# Express. Instead of choosing the Run button when I clicked the link, I choose to save the package to my desktop so I can pull it apart and look at the contents.
  2. Extract the contents of the setup package - when I save the package to my desktop I notice that the icon is a familiar one that normally indicates that the package is an IExpress self-extracting EXE. So I tried to open the package by using IExpress command line parameters to extract but not run the setup - vcssetup.exe /t:c:\temp /c (I know this syntax because the .NET Framework is an IExpress package and I commonly need to extract the MSI to help customers repair broken .NET Framework installations)
  3. Look at the extracted contents - Since there are a bunch of binary and non-binary files in the package, I make an educated guess that there is a generic setup.exe that is used for all Express Editions and there is some kind of data file in the self-extracting package that allows individual products to customize their appearance and/or behavior. As a result, I started out looking for files that appear to be data files that are used by setup.exe to control the behavior of C# Express setup. 
  4. Look for INI files - I find a file named locdata.ini. Opening that file in notepad shows a bunch of ComponentName values, so this appears to not be very useful for what I'm looking for (side note - in fact this is a list of strings used in setup UI so that setup can be localized).
  5. Look for files named setup.* - Doing this takes me to a file named setup.sdb. When I open this in notepad the results are much more promising. There is a bunch of information about "dialog pages" and even an item named BootstrapperURL at the top that use the syntax fwlink/?LinkId=##### . Since I noticed that the link I originally downloaded C# Express from was of the form http://go.microsoft.com/fwlink/?LinkId=\#\#\#\#\# I decide to try copying the BootstrapperURL and building a full URL using the prefix http://go.microsoft.com/ . When I enter that in my browser and choose Go I get a prompt to download vcssetup.exe again. So I'm getting closer but I'm not quite there yet.
  6. Look deeper into setup.sdb - As I continue to look at the contents of setup.sdb, I find a section named [VS Custom]. I see an entry in there that has the data ComponentFile=baseline.dat.Previously, I also happened to notice that the setup package I extracted contains a file named baseline.dat, so I decide to look there next.
  7. Look at baseline.dat - This file looks like it has a list of components that are part of C# Express setup or are prerequisites that setup does not install but requires to be present on the machine. Some of the components sections have URL values that use the syntax fwlink/?LinkId=##### just like the BootstrapperURL value in setup.sdb. I try to use the same trick as above to build a full URL for the item in [gencomp18] and I'm prompted to download dotnetfx.exe. So I've found the direct download location for the .NET Framework 2.0 beta 2 package! I build similar URLs for [vs_setup.dll] for the main C# Express installer, [gencomp30] for MSDN Express and [gencomp31] for SQL Express.

The only remaining trick is how to translate from the "fwlink" to the actual location on the Microsoft download center. Microsoft uses the concept of an "fwlink" (or forwarding link) to provide a public link that can be changed to a new location via some server-side settings later on. This is useful to allow users or other Microsoft products to link to locations and always have their links point to the most up-to-date versions of documents or products, even after other products have shipped with these links embedded in the product code or documentation. I have to admit I'm not much of an expert on networking, so the exact method of translating this is left an exercise for the reader :-) If anyone has an easy way to do this, please post a comment and I'll give it a try.