Deployment issues with NuGet packages- Help wanted

[Chadders187]

Apologies if I've gone the wrong way in going about this...

I've started using the ExcelDNA package in a NetFramework 4.7.2 project using a packages.config approach (as per the guidance). The majority of the project dependencies are NuGet packages. There are no project references.

My debugging experience is great - no issues. However, upon deployment to Excel the functions do not work unless dlls are added alongside the xll file. My understanding is that this shouldn't be required unless packaged incorrectly. The pack log in the output window shows success with no issues.

At this point, I have not made any updates to the .dna file. Presumably, I should not have to duplicate everything in my packages.config by adding manually into my .dna file? Is there something that I'm missing?

Any help much appreciated.

[raymondjstone]

How are you planning on deploying the add-in?

I have examples using Wix as a deployment tool and that works fine but needs quite a few moving parts to be added for what I was doing including active setup configurations in my case.

[govert]

@Chadders187 - Under the 'PackageReference' style, the ExcelDnaPack step should still be running and giving you -packed.xll versions of your add-in. Can you check this? Any assemblies that you want packed into the single-file -packed.xll add-in needs to be mentioned in the .dna file, either as <ExternalReference ... Pack='true' /> or `<Reference ... Pack='true' />' tags.

[govert]

You see exactly which assemblies are packed into the -packaed.xll file by looking at the build output. Only assemblies that are shown to be packed here can be removed from your distribution because there is a copy inside the -packed.xll.

[Chadders187]

How are you planning on deploying the add-in?

@raymondjstone We are just looking to take the packed xll file and move it to the XLSTART area for our users. The latter is all fine. It's just that the xll file is seemingly insufficient on its own.

Under the 'PackageReference' style, the ExcelDnaPack step should still be running and giving you -packed.xll versions of your add-in. Can you check this?

@govert As in, switch to <RestoreProjectStyle>PackageReference</RestoreProjectStyle>, switch the appropriate build.props flag to false and try again? If so, that has worked in terms of building successfully but unfortunately the pack output (below) didn't change. Would this work if reinstalling the ExcelDna add-in though?

Any assemblies that you want packed into the single-file -packed.xll add-in needs to be mentioned in the .dna file, either as <ExternalReference ... Pack='true' /> or `<Reference ... Pack='true' />' tags.

@govert There must only be a few cases where you'd not want all of the NuGet references in the Packages.config (and their dependencies) to be packed though? Which means I'd have to add `<Reference ... Pack='true' />' for all of the dlls in my bin folder? And also make adjustments anytime packages are added and/or package dependencies were updated?

More detail here...

[govert]

There is currently no interaction between the PackageReference format and the ExcelDnaPack utility. So assemblies that you want to have packed in the .xll file need to be listed in the .dna file. You suggestion to somehow integrate the references in the project file with the packing is an interesting one. Another option might be to support some kind of glob string in the .dna file, like <Reference Path='*.dll' Pack='true' />. But for now you have to do the work, or write the code that generates or updates the .dna file yourself.

[Chadders187]

@govert Thanks for all the quick responses. Both that and the product itself are much appreciated!

Should I turn this into a feature request of some kind then?

[govert]

@Chadders187 Yes - that would be great. Especially if you can add some detail on how you think this should work (e.g. how to opt in / out of the mechanism, how to exclude some assemblies, how to deal with native assemblies which can't be packed). I have no experience with the new project format myself, so it's hard to know what users would expect, or what would fit in nicely.

[Chadders187]

@govert I'm going to put something together now.

On your project format point, I think the project format is irrelevant to a large extent. Regardless of whether using a packages.config file or the PackageReference style the outcome is the same for me. Therefore I'll be focussing on what's in the build folder as opposed to the structure of the project itself.