Improve debugging experience / Automatically set debugger options

[augustoproiete]

This PR resolves issues #18 and #19.

The main goal of this PR is to improve the debugging experience of ExcelDna add-ins by automatically detecting the latest Excel version installed on the machine, as well as Excel's bitness (i.e. 32-bit or 64-bit), and set the debugger options in the project where ExcelDna.AddIn is installed, on every build, to the Excel detected, and the right add-in (32 or 64) to be opened with Excel.

This PR allows the following user experiences:

1. Start debugging an add-in immediately after downloading code from source control, regardless of the Excel version that the original developer was using, without having to define any setting in the project debug configuration;

2. Start debugging an add-in immediately after renaming the .dna file, without having to change any setting in the project configuration (as it automatically updates the debug settings with the new .xll file name);

3. Start debugging an add-in immediately after changing suffixes for add-ins in the ExcelDna.Build.props file, without having to change any setting in the project configuration (as it automatically updates the debug settings with the new .xll file name);

4. Dynamically target different Excel installations on the machine via conditions in ExcelDna.Build.props.

---

How to override the default behavior

The ExcelDna.Build.props that gets added into the Properties folder of the add-in, includes three (3) new variables:

• RunExcelDnaSetDebuggerOptions - Allows the user to turn off/on setting the debug options during build;

• ExcelDnaExcelExePath - Allows the user to override the default behavior of using the most recent version of Excel installed on the machine, and instead use a particular Excel installation, by providing the full path of the EXCEL.EXE that should be used;

• ExcelDnaAddInForDebugging - Allows the user to override the default behavior of using the add-in that matches the EXCEL.EXE bitness (i.e. 32-bit or 64-bit), and instead use a particular add-in, by providing the file name of the .xll file that should be passed to EXCEL.EXE as an argument.

Of course, ideally users would use the variables above only for tests during debugging sessions, and change them back to their original values before committing the ExcelDna.Build.props file to source control, as changes to these variables would impact the user experiences described earlier above.

---

I tested this PR with C#, VB .NET, and F# projects on Visual Studio 2017 (Enterprise and Community) as well as Visual Studio 2015 (Enterprise), and would welcome any further testing.

---

/cc @govert, @garethhayter, @konne

[govert]

This looks great - Thanks @augustoproiete !