Improve support for custom command-line arguments when debugging add-ins

[augustoproiete]

As per described in Debug Command Line Argument behavior difference between V 0.34.6 and V1.0 and Excel-Dna v1.0 rc - overwrites command line option.

[govert]

I'm not sure what would be better than the current plan, where there is an opt-out setting to not run the debug rewrite.

[augustoproiete]

@govert I'm thinking there's a couple of things we might want to consider:

1. Modify our build task to honor the value that the user sets in ExcelDnaAddInForDebugging instead of always using the file name on a relative path. That allows the user to use a fully qualified path if they want, and may do the trick, as it would allow the user to type in more arguments there such as the XLSX file path or name.

2. Modify our .props template to support an additional parameter e.g. ExcelDnaCmdLineArgs in the same property group to allow the user to specify additional arguments explicitly, without losing the functionality of the Excel bitness discovery that sets the XLL name.

What do you think?

[govert]

@augustoproiete I'd be happy with either of these options, but it seems like a marginal benefit over the current opt-out option. Do you think many people rebuild and debug both 32-bit and 64-bit versions often, and require special command line args?

[augustoproiete]

@govert Even if not many users actually rely on these features directly, the fact that it's forcing some people to completely disable the build task will affect people that rely on the happy path and will no longer have a good experience.

That is because a dev that needs to disable the feature in the .props file, will likely commit the change to source control... That means anyone else in the team now won't have the nice debugging experience that this feature is all about:

Open the add-in project in Visual Studio, run it, and it "just works"(tm)... Figure out where my Excel.exe is, and figure out if you should use the 32-bit add-in or 64-bit add-in, ... Magic.

Along the same lines it's a common part of devs to cleanup their repository every so often, mostly to resolve caching issues and other bugs with Visual Studio, ReSharper, etc... e.g. A dev using Git, will often run a git clean -fxd to get rid of the .vs folders, .user files, etc... Causing them to lose the path to the local Excel, the name of the correct add-in to run, etc. which won't be set up again, with the build task disabled, so bad running/debugging experience again.