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.

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

See original GitHub issue

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


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


  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


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

Known issues

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

Issue Analytics

  • State:open
  • Created 5 years ago
  • Reactions:2
  • Comments:13 (9 by maintainers)

github_iconTop GitHub Comments

augustoproietecommented, Dec 4, 2020

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">



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


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.

augustoproietecommented, Sep 9, 2020

@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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Update ExcelDnaDoc NuGet Package to support the new ...
AddIn's install.ps1 does, and adds a reference to ExcelDna.Documentation.dll in the .dna file for it to be packed.
Read more >
Excel-DNA is not compatible with projects that use NuGet ` ...
I tried to modify the NuGet Package option, switching from PackageReference to Package.config without success (and I made sure to uninstall and ...
Read more >
Blog | Excel-DNA
AddIn NuGet package now supports references in SDK-style project files. For new projects, this means that a .dna file is no longer added...
Read more >
Migrate from packages.config to PackageReference
Details on how to migrate a project from the packages.config management format to PackageReference as supported by NuGet 4.0+ and VS2017 and ...
Read more >
ExcelDna.CellAddress 1.0.2
ExcelDna Cell Address Extensions,support Range and ExcelReference formats. ... Versions Compatible and additional computed target framework ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found