Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Improve the way we determine the path for Excel and add-in platform, for debugging

See original GitHub issue

This is somewhat related to issue #18, where I’m proposing that we move the Excel.exe path and add-in to the project file, so that the debugging information is persisted in source control, and any developer that clones the repository would then be able to debug the add-in without having to configure anything.

We know that we can’t control what version of Excel each developer has installed on his/her machine… Some developers run Excel 2010 32-bit, others run Excel 2010 64-bit, others Excel 2013 64-bit, etc.

I’d like a developer to be able to clone my repository, open my solution in Visual Studio, and just hit F5 and be able to Debug it, starting an instance of the Excel installed on his/her machine, no matter what version is there, and with the right add-in XLL file (x64 or x86) for that debugging session.

Whilst I don’t have a perfect solution for that yet, I do have a workaround that have been working well for most cases: Inside the project file, I add a few conditional property groups that define the StartProgram variable with the correct path of the Excel on the machine (if matches any, of course)

<PropertyGroup Condition="'$(StartProgram)' == '' AND Exists('C:\Program Files\Microsoft Office\Office15\EXCEL.EXE')">
  <StartProgram>C:\Program Files\Microsoft Office\Office15\EXCEL.EXE</StartProgram>
</PropertyGroup>
<PropertyGroup Condition="'$(StartProgram)' == '' AND Exists('C:\Program Files\Microsoft Office\Office14\EXCEL.EXE')">
  <StartProgram>C:\Program Files\Microsoft Office\Office14\EXCEL.EXE</StartProgram>
</PropertyGroup>
<!-- etc... -->

I also have the similar conditionals for 32-bit Excel installed on Windows 64-bit machines:

<PropertyGroup Condition="'$(StartProgram)' == '' AND Exists('C:\Program Files (x86)\Microsoft Office\Office15\EXCEL.EXE')">
  <StartProgram>C:\Program Files (x86)\Microsoft Office\Office15\EXCEL.EXE</StartProgram>
</PropertyGroup>
<PropertyGroup Condition="'$(StartProgram)' == '' AND Exists('C:\Program Files (x86)\Microsoft Office\Office14\EXCEL.EXE')">
  <StartProgram>C:\Program Files (x86)\Microsoft Office\Office14\EXCEL.EXE</StartProgram>
</PropertyGroup>
<!-- etc... -->

And a similar kind of test is applied to determine the right add-in to execute (32-bit or 64-bit)

  <PropertyGroup Condition="'$(StartProgram)' != '' AND $(StartProgram.Contains('Program Files (x86)'))">
    <StartArguments>"MyXL-AddIn.xll"</StartArguments>
  </PropertyGroup>
  <PropertyGroup Condition="'$(StartProgram)' != '' AND (! $(StartProgram.Contains('Program Files (x86)')) )">
    <StartArguments>"MyXL-AddIn64.xll"</StartArguments>
  </PropertyGroup>

And finally, conditional to set the StartAction property

<PropertyGroup Condition="'$(StartProgram)' != ''">
  <StartAction>Program</StartAction>
</PropertyGroup>

What are your thoughts on this (or something like this)?

ps: These MSBuild instructions don’t necessarily need to be on the .csproj (could be a custom .targets file added to the project to make it easier to edit from within Visual Studio).