Battling to use packed xll with Office 365

148 views
Skip to first unread message

Andre Sharpe

unread,
Apr 13, 2025, 4:30:45 PM4/13/25
to Excel-DNA
I am using the latest version of Excel-DNA on nuget (and have also tried the beta2) on dotnet 6. When opening the packed xll i get a "buffer can not be null" error when the dll is unpacking the .dna file on excel startup.  The unpacked versions work fine (both debug and release versions).

Any idea what I'm doing wrong?

Govert van Drimmelen

unread,
Apr 13, 2025, 4:34:55 PM4/13/25
to exce...@googlegroups.com

Does it work with the previous Excel-DNA version?
The list of packed libraries are shown in the build output. Anything suspicious there?
Maybe a weird named file or 0 length   library.
Can you make a small project that exhibits the error?

-Govert


On Sun, 13 Apr 2025, 22:30 Andre Sharpe, <andre....@gmail.com> wrote:
I am using the latest version of Excel-DNA on nuget (and have also tried the beta2) on dotnet 6. When opening the packed xll i get a "buffer can not be null" error when the dll is unpacking the .dna file on excel startup.  The unpacked versions work fine (both debug and release versions).

Any idea what I'm doing wrong?

--
You received this message because you are subscribed to the Google Groups "Excel-DNA" group.
To unsubscribe from this group and stop receiving emails from it, send an email to exceldna+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/exceldna/991e060f-9eb7-4a63-af89-44ea16b47202n%40googlegroups.com.

Andre Sharpe

unread,
Apr 13, 2025, 5:05:41 PM4/13/25
to Excel-DNA
Hi Govert

I made a small version of the project and posted it here  andresharpe/AtlasGeoAddin

The error output was saved to this file in the repo: AtlasGeoAddin/ErrorOutput.txt at master · andresharpe/AtlasGeoAddin

It contains:
Initialization [Error] There was an error in processing .dna file bytes:
Buffer cannot be null. (Parameter 'buffer')
Initialization [Error] External library could not be registered - Path: packed:ATLAS.DNA
 - Packed DnaLibrary could not be loaded


My installed Excel version is :

Microsoft Office version 16.0.18623.20156. This is Excel 365 (indicated by version 16.0), and the full build number is 18623.20156.

Trust centre shows all macros are enabled, and doesn't require signing. And the unpacked version works fine.

Andre

Andre Sharpe

unread,
Apr 13, 2025, 5:07:56 PM4/13/25
to Excel-DNA
Build output looks fine...


Build started at 22:54...
1>------ Build started: Project: Atlas.Dna, Configuration: Debug Any CPU ------
1>---
1>ExcelDnaSetLaunchSettings: EXCEL.EXE path for debugging: C:\Program Files\Microsoft Office\root\Office16\EXCEL.EXE
1>ExcelDnaSetLaunchSettings: Add-In for debugging: bin\Debug\net6.0-windows\Atlas.Dna-AddIn64.xll
1>Atlas.Dna -> C:\Users\andre\repos\AtlasGeoAddin\src\Atlas.Dna\bin\Debug\net6.0-windows\Atlas.Dna.dll
1>---
1>ExcelDnaBuild:  -> bin\Debug\net6.0-windows\Atlas.Dna-AddIn.dna
1>ExcelDnaBuild: ..\..\..\..\.nuget\packages\exceldna.addin\1.9.0-beta2\build\..\tools\\net6.0-windows7.0\ExcelDna.xll -> bin\Debug\net6.0-windows\Atlas.Dna-AddIn.xll
1>ExcelDnaBuild: bin\Debug\net6.0-windows\Atlas.Dna.deps.json -> bin\Debug\net6.0-windows\Atlas.Dna-AddIn.deps.json
1>ExcelDnaBuild: ---
1>ExcelDnaBuild:  -> bin\Debug\net6.0-windows\Atlas.Dna-AddIn64.dna
1>ExcelDnaBuild: ..\..\..\..\.nuget\packages\exceldna.addin\1.9.0-beta2\build\..\tools\\net6.0-windows7.0\ExcelDna64.xll -> bin\Debug\net6.0-windows\Atlas.Dna-AddIn64.xll
1>ExcelDnaBuild: bin\Debug\net6.0-windows\Atlas.Dna.deps.json -> bin\Debug\net6.0-windows\Atlas.Dna-AddIn64.deps.json
1>---
1>ExcelDnaPack: bin\Debug\net6.0-windows\Atlas.Dna-AddIn.dna -> bin\Debug\net6.0-windows\publish\Atlas.Dna-AddIn-packed.xll
1>PackExcelAddIn: Using base add-in bin\Debug\net6.0-windows\Atlas.Dna-AddIn.xll
1>PackExcelAddIn:   ~~> ExternalLibrary path Atlas.Dna.dll resolved to bin\Debug\net6.0-windows\Atlas.Dna.dll.
1>PackExcelAddIn:   ->  Updating resource: Type: DNA, Name: __MAIN__, Length: 595
1>PackExcelAddIn:   ->  Updating resource: Type: ASSEMBLY_LZMA, Name: ATLAS.DNA, Length: 1701
1>PackExcelAddIn:   ->  Updating resource: Type: ASSEMBLY_LZMA, Name: EXCELDNA.INTELLISENSE, Source: Managed deps.json, Length: 41345
1>PackExcelAddIn: Completed Packing bin\Debug\net6.0-windows\publish\Atlas.Dna-AddIn-packed.xll.
1>ExcelDnaPack: bin\Debug\net6.0-windows\Atlas.Dna-AddIn64.dna -> bin\Debug\net6.0-windows\publish\Atlas.Dna-AddIn64-packed.xll
1>PackExcelAddIn: Using base add-in bin\Debug\net6.0-windows\Atlas.Dna-AddIn64.xll
1>PackExcelAddIn:   ~~> ExternalLibrary path Atlas.Dna.dll resolved to bin\Debug\net6.0-windows\Atlas.Dna.dll.
1>PackExcelAddIn:   ->  Updating resource: Type: DNA, Name: __MAIN__, Length: 595
1>PackExcelAddIn:   ->  Updating resource: Type: ASSEMBLY_LZMA, Name: ATLAS.DNA, Length: 1701
1>PackExcelAddIn:   ->  Updating resource: Type: ASSEMBLY_LZMA, Name: EXCELDNA.INTELLISENSE, Source: Managed deps.json, Length: 41345
1>PackExcelAddIn: Completed Packing bin\Debug\net6.0-windows\publish\Atlas.Dna-AddIn64-packed.xll.
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
========== Build completed at 22:54 and took 01.174 seconds ==========


Govert van Drimmelen

unread,
Apr 14, 2025, 4:32:51 AM4/14/25
to Excel-DNA
Hi Andre,

You've found a bug in how Excel-DNA deals with some assembly names when packing/unpacking.
In particular, your project named "Atlas.Dna" compiles to an assembly called "Atlas.Dna.dll" and is packed as "ATLAS.DNA".
This name confuses the Excel-DNA unpacking and thing go wrong from there.

The problem is also present when targeting .NET Framework and in older Excel-DNA versions.

A workaround is to change the project name or explicitly set the output assembly name in a project property:
<AssemblyName>Atlas-Dna</AssemblyName>
   
I've created a GitHub issue to track this: https://github.com/Excel-DNA/ExcelDna/issues/760
It should be fixed for the v1.9.0 release.

Thank you for reporting this.

Regards,
Govert

Andre Sharpe

unread,
Apr 14, 2025, 4:58:28 AM4/14/25
to Excel-DNA
Awesome - thanks Govert. I'll apply the AssemblyName fix.

This is an excellent product. It's come a long way since Mr Chris Muller pointed me at it all those years ago!

The support is also just impressive.

Keep it up!
Andre


Reply all
Reply to author
Forward
0 new messages