Debug instructions to run Excel should be stored in the project file

[augustoproiete]

When I install the Excel-DNA NuGet package, it adds the instructions to allow me to debug the add-in by starting Excel and passing the add-in file as a parameter, which is great.

Unfortunately it doesn't make this change in the project file (e.g. .csproj). Instead, it updates the user's file related to the project (e.g. .csproj.user) which is individual for each developer, and therefore is not committed to the source control.

Example of a .csproj.user file:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/ ...">
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|AnyCPU'">
    <StartAction>Program</StartAction>
    <StartProgram>C:\Program Files\Microsoft Office\Office15\EXCEL.EXE</StartProgram>
    <StartArguments>"MyExcelAddIn-AddIn.xll"</StartArguments>
  </PropertyGroup>
</Project>

In practice, what happens is that when a developer clones a repository from source control and tries to debug it, it never works...

The workaround so far, is to manually copy/paste the contents of the .csproj.user file into the .csproj file.

Example of a manually changed .csproj file:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <!-- ... -->
  <PropertyGroup>
    <!-- ... -->
    <TargetFrameworkVersion>v4.5.1</TargetFrameworkVersion>
    <FileAlignment>512</FileAlignment>
    <StartAction>Program</StartAction>
    <StartProgram>C:\Program Files\Microsoft Office\Office15\EXCEL.EXE</StartProgram>
    <StartArguments>"MyExcelAddIn-AddIn.xll"</StartArguments>
  </PropertyGroup>
  <!-- ... -->

---

What I would like, is for the NuGet package to update the .csproj file with the StartAction, StartProgram and StartArguments, instead of updating the .csproj.user file (and equivalent for other languages).

[govert]

How do we determine where these setting are stored from the Install.ps1 script?

[augustoproiete]

@govert: I don't know yet, but will investigate.

[govert]

The Install.ps1 story is a pain, but I don't know of a better way to get these settings configured. If there's a supported way through the DTE COM object model to specify whether the changes go into csproj or csproj.user, I'd be very grateful for a fix.

On the other hand, if we have to parse and edit the csproj .xml file to insert this, I think that would be going too far, and then I'd rather leave it the way it is. I don't know what other packages do...

Another approach might be to make some project templates that can be used instead of (or in addition to) the NuGet package. Then the project template might contain all the clever bits in the csproj file already, and there's no problem of injecting it.

[augustoproiete]

I'll do some tests as part of #17 and get back on this one. I know we can easily add a custom .targets file to the .csproj via Install.ps1, so (in theory) we could have these attributes inside the .targets and not have to parse anything. We'll see.

[govert]

That sounds good.

I suggest for v 0.33 that I just fix the path issues in Install.ps1 that your identified in #16 (I'll do that, maybe you can help test when I'm ready).

Then we add a custom .targets for the next version, with your suggestions here and #17 . Maybe you can look into that. I don't know anything about custom .targets.

[augustoproiete]

Sounds like a plan. Happy to help test v0.33.

Leave the .targets with me... I'll send you a PR in the next few days.

[konne]

Hi, how you determine which excel version is installed or would be used. I think this theme is more complex and I really like that this is stored in the csproj.user

[augustoproiete]

Hey @konne!

I'll get the path from the registry, based on Microsoft's docs on "How to Determine the Path for an Office Application", unless someone have a better idea :)

[konne]

Hi,

thats okay, but there have to be a possibility to override this. I have for example a testmachine with different offices installed on the same machine and there I like to definge which Office ist started for my tests.

@augustoproiete: thanks for you working on a better msbuild process. I have already made build task for my project, but you make it real general 👍
@augustoproiete: do you also plan to make a real msbuild task for the ExcelDNA Pack?

bye
Konne

[augustoproiete]

@konne: Great!

Yes, makes sense to be able to override it. As soon as I get a v1.0 of the MSBuild process (you can follow issue #17 & pull-request #27) merged, I'll work on this one.

My idea is to have the definitions of how to start the project (and the Excel path, etc.) in the .targets file that gets included in the .csproj, which will default to the value found the registry (dynamically), but will also allow the developer to override it via a properties file included in the project (i.e. the ExcelDna.AddIn.props that you can see in #27).

Would be great to have your help on testing/trying to break this one and also the build process. I'll make sure I'll ping you when I update #27 or this one.

About ExcelDnaPack being a MSBuild task, that would my end-goal if I can manage to convince @govert :).

ps. I've seen your recent 2 PRs and they look quite useful! Thanks for contributing!

[konne]

@augustoproiete: yes, i will test it, please write me a small hint.
MSBuildtask -> I change at the moment a lot in the ExcelDNAPack, so it make sense to start the msbuild task after that.

[augustoproiete]

Added some thoughts on #19 (comment) which would enable us to resolve this one as well

[augustoproiete]

This is resolved by PR #147

I went with a different approach than what I initially suggested when I created this issue back in 2015, and instead of modifying the .csproj with the values that we need, I use the same approach as the install Powershell script uses, and set the debug properties via DTE, which in turn saves the information into a csproj.user file on the side (a file that is typically not be committed to source control), and I do that on every build, effectively regenerating the csproj.user file with the correct settings.

This achieves my main goal in the issue, and others described in the PR #147:

In practice, what happens is that when a developer clones a repository from source control and tries to debug it, it never works...