The Right Stuff

After listening to the Hanselminutes episode on Microsoft Solver Foundation (MSF) I decided it’s time to give it a shot today. Solver Foundation seems to be a solution to a set of constrained problems I sometimes face:

• Sharing costs and calculating minimal money transfers after trips with my friends, where each friend spent some money.
• Giving out questions to attendees of our User Group “Boot Camps”: Speakers prepare ~20 questions, ranging from easy to moderate levels. We assign each attendee an easy question and one to chew a bit upon. Further, every question should be given out to two attendees, so in case someone doesn’t make it to the meeting we’re still able to cover the question.

Something I don’t remember Scott Hanselman and his guest talking about is that Solver Foundation comes with an Excel Add-In that is supposed to make creating models easy easier, no code needed. Along with the “Solver Foundation for Excel Primer” document that is installed along with the binaries I figured Excel would be a good way to start looking into Solver Foundation.

After the MSI ran, I started Excel but didn’t find the Solver Foundation tab that’s advertised in the primer. The COM Add-Ins dialog said something about that the Add-In could not be loaded. Nice! Luckily the Event Viewer was more helpful in terms of error messages where I found this beauty of an exception:

Microsoft.VisualStudio.Tools.Applications.Runtime.CannotCreateCustomizationDomainException:
Customization could not be loaded because the application domain could not be created.
---> System.IO.FileLoadException: Could not load file or assembly 'MicrosoftSolverFoundationForExcel, Version=1.0.6.4890, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies.
The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

My first guess was that an old MSF assembly was referenced and I decided to go with an assembly binding redirect for excel.exe. Didn’t help. The next step was to get into the innards of VSTO deployment. What I found in the MicrosoftSolverFoundationForExcel.vsto and MicrosoftSolverFoundationForExcel.dll.manifest files wasn’t surpising: Several references to old versions of MSF. None of which were deployed by the MSI installer, so Excel trying to load such dependencies failed.

<assemblyIdentity name="MicrosoftSolverFoundationForExcel" version="1.0.8.6048"…
<assemblyIdentity name="MicrosoftSolverFoundationForExcel" version="1.0.6.4890"…

I updated both references to the match the installed version 2.0.2.8632, just to find myself faced with another error saying that the manifest’s digital signature is broken.

Now was time to contact my friend Lars Keller who is an expert in VSTO development. Lars told me that I would have to re-sign the .vsto and .manifest files to make the signature reflect my changes. The Office Development with Visual Studio blog has the full details.

1. I had to create a certificate that can be used for code signing:

   makecert -r -pe -n "CN=Your Name" -b 01/01/2010 -e 01/01/2099 -eku 1.3.6.1.5.5.7.3.3 -ss My

2. Export the certificate as a PFX file using certmgr.msc
3. Create a backup copy of the MSF Excel Add-In .manifest and .vsto files
4. Open a Visual Studio Command prompt and navigate to the manifest's location
5. Make edits to the manifest file correcting the assembly versions of MicrosoftSolverFoundationForExcel to 2.0.2.8632
6. Update the digital signatures for both the manifest and the VSTO file:

   mage.exe -update MicrosoftSolverFoundationForExcel.dll.manifest -CertFile <your-cert.pfx> -Password <cert-export-password>
   mage.exe -update MicrosoftSolverFoundationForExcel.vsto -appmanifest MicrosoftSolverFoundationForExcel.dll.manifest -CertFile <your-cert.pfx> -Password <cert-export-password>

7. Restart Excel, the Solver Foundation tab should be on the ribbon

(Tested with Office 2010 beta.)

Scott Hanselman recently wrote about the Debugging Tools for Windows and their usefulness in conjunction with Process Explorer. Today I needed the Debugging Tools on a server where an ASP.NET application was running with 100% load on one CPU core with lots of context switches.

When you open Process Explorer's Threads tab for a certain process, Process Explorer will approximate function names and display offsets if the Debugging Tools are not installed. When Process Explorer is configured to use the Debugging Tools and Microsoft Symbol Servers it will display actual function names instead of obscure offsets.

Offsets	Function Names

Being the kind of guy I am, I opted for a minimal installation of the Debugging Tools, that is just the "Tools" and "Helpful Tools" branches displayed in the installer. This also installs dbghelp.dll which is needed for Symbol Server support. After setting the NT symbol path environment variable and pointing Process Explorer to %ProgramFiles%\Debugging Tools for Windows\dbghelp.dll everything should have worked. So I opened Process Explorer, displayed the properties of some process, opened the Threads tabs …and saw function offsets.

What happened? After some Filemon investigation I found that the symbol path wasn't touched by Process Explorer, no PDBs were downloaded and thus just offsets could be displayed. I got the idea that some Debugging Tools component was missing and installed the full package. Lo and behold, the function names were shown!

After playing around I found that the only component you need install to get Symbol Server support is the "Debuggers" branch. This will also get you WinDbg, a basic yet powerful debugger for Windows with plugin support. Mental note: Try WinDbg.

Aren't these the tools from the basement, Torsten? :-)