Update ExcelDna.AddIn NuGet Package to support the new PackageReference format

Spin-off of #138 to discuss how we want to support the PackageReference format in the ExcelDna.AddIn NuGet package. This relates to #188

Background

• Currently ExcelDna.AddIn relies on PowerShell scripts for installing and uninstalling the package which basically do the following:

install.ps1

1. Rename an _UNINSTALLED_$(ProjectName) to $(ProjectName)-AddIn.dna, if it exists Which would have happened after the user uninstalled a previous version of ExcelDna
2. Add a $(ProjectName)-AddIn.dna file, if step 1 didn’t find an old file 2.1. Perform some string replacements inside the .dna file added to include $(ProjectName)
3. ~Add a reference to the .targets file~ Update 2018-05-18: This is now done automatically by a NuGet feature implemented by #167

uninstall.ps1

1. Rename an existing $(ProjectName)-AddIn.dna file to _UNINSTALLED_$(ProjectName), if it exists

Known issues

• The PackageReference format does not support the install.ps1 and uninstall.ps1 PowerShell scripts
• The PackageReference format also does not support content files the same way they do with the packages.config format and introduce another feature contentFiles that behaves in a different way where files are meant to be immutable and therefore they are not shown in the project tree, and are not editable. The (terrible IMO) recommendation from the NuGet team is to “… copy them to the project manually if you need to edit the files …” 😞
• With the current approach (powershell scripts) If the user renames the .dna file to anything else that is not $(ProjectName)-AddIn, the script doesn’t work anymore

Proposed solution

I propose we do the following:

1. Remove the install.ps1 and uninstall.ps1 PowerShell scripts from the NuGet package
2. Rename the ExcelDna-Template.dna to AddIn.dna.pp and use NuGet’s source code transformation feature to do the replacements inside the .dna file
3. Document that the user must manually copy the .dna file to the project when using PackageReference (until the NuGet team gives us an alternative) 🙅‍♂️
4. Update our build process (i.e. ExcelDnaBuild task) to - by convention - use $(ProjectName) as the name of the .xll, if it sees a file named AddIn.dna file in the project. If the user renames it to something else, then use the name of the .dna file for the output .xll

[augustoproiete]

Hey @andysprague44 ! Small world 😃

You shouldn’t need any of that code if you’re using the latest version of Excel-DNA (v1.1.1 as of this writing) as all of that is handled for you by Excel-DNA’s build process (even in an SDK-style/PackageReference project). So there’s basically only two switches you need to change for it to work (with some limitations (*)):

• Turn on ExcelDnaAllowPackageReferenceProjectStyle to ignore the error that SDK-style projects are not supported
• Turn off RunExcelDnaSetDebuggerOptions to disable the automatic configuration of Visual Studio debugging settings

This should be all you need:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net48</TargetFramework>
  </PropertyGroup>

  <PropertyGroup>
    <ExcelDnaAllowPackageReferenceProjectStyle>true</ExcelDnaAllowPackageReferenceProjectStyle>
    <RunExcelDnaSetDebuggerOptions>false</RunExcelDnaSetDebuggerOptions>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="ExcelDna.AddIn" Version="1.1.1" PrivateAssets="All" />
  </ItemGroup>

</Project>

NB: Change the TargetFramework as needed depending on what .NET Framework version your add-in users have on their machines.

* The feature you’ll be missing out when using Excel-DNA with SDK-style/PackageReference projects today is the automatic debugging configuration settings that does two things:

1. Look up where Excel is installed on your machine, and configure Visual Studio to run it (and attach the debugger to) when you press F5 / start a debugging session.

2. Determine if your Excel installation is 32-bit or 64-bit and automatically configure Visual Studio with the the correct .xll to be opened together with Excel when you press F5 / start a debugging session.

SDK-style/PackageReference projects no longer use the .csproj.user to store debugging settings so the API that we use to configure debugging is disabled in the new project system.

The current workaround is to (manually) create multiple profiles in your launchSettings.json (one for each machine/developer) and store it in source control, so that you can debug your add-in without having to configure this every time.

[augustoproiete]

@xp44mm The latest version of Excel-DNA as of this writing (v1.1.1) doesn’t support PackageReference and by default displays the error message you’re seeing.

The recommendation at this time is to use the Class Library (.NET Framework) project type instead of Class Library (.NET Standard) project type to get the best development & debugging experience.

If you want to use the new SDK-style project at your own risk, you can set ExcelDnaAllowPackageReferenceProjectStyle to true in your ExcelDna.Build.props. See PR #327 for more details.