After figuring out the previous problem (DLL dependencies), I decided to install the .NET Framework SDK into the VPC image (a Windows Server 2003). No such luck: "Extracting file failed. It is most likely caused by low memory (low disk space for swapping file) or corrupted Cabinet file." No, not again a memory issue...
Wait a second! That image has 400 megs of memory assigned plus a 1.2 gig growth limit for the swap file. That can't be. As usual, I used Google to search for solutions. One (older) suggestion was to update Windows Installer - I gave it a shot anyways, and installed Windows Installer 3.0. No change, but that was expected. At least I am now up2date in that respect.
To spare myself further waste of time, I decided to take the easy route and ran
on my XP box, copied the extracted setup files to the VPC image - and presto! The SDK is installing like a charm.
Once again it pays off to be in this game... erm industry for so long: I got a weird Fusion loading error for an assembly:
System.Reflection.TargetInvocationException: Exception has been thrown by the target of
an invocation. ---> System.IO.FileNotFoundException: File or assembly name ConsoleControl,
or one of its dependencies, was not found.
File name: "ConsoleControl" at ConsolePad..ctor()
=== Pre-bind state information ===
LOG: DisplayName = ConsoleControl, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null
LOG: Appbase = C:\SharpDevelop\Repository\SharpDevelop\bin\
LOG: Initial PrivatePath = NULL
Calling assembly : ConsoleAddin, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null.
LOG: Policy not being applied to reference at this time (private, custom, partial,
or location-based assembly bind).
LOG: Post-policy reference: ConsoleControl, Version=0.0.0.0, Culture=neutral,
LOG: Attempting download of new URL
The assembly of course was right smack where the above URL is pointing to. So what was going on? First, I mailed the dev - no such luck, it was working on his machine (as if I would care: "I don't care if it runs on your machine, we are not shipping your machine!", Software Testers Anonymous).
As the test machine is a non-SDK machine (runtime installed only), fuslogvw was also out of the question. Mer...veilleux. Fallback to tools a C++ programmer loves and knows: Dependency Walker. This guy produced the following output:
A-ha! The dev checked in an assembly that was written in C++ (and thus he had all the runtime assemblies on his box), but he forgot the two beauties msvcp71 and msvcr71. Chalk one up for the old dogs.