ExcelDnaPack not working with MSBuildRuntimeType == "Core" and target .NET framework 4.6
Sandoli opened this issue · 5 comments
While trying to port an old project from ExcelDNA 1.1 to ExcelDNA 1.6, I face a weird issue.
If I build with MSBuild then the packed .xll in the publish folder is fully functional and can be loaded by Excel.
If I build with dotnet build my .xll looks broken as it cannot be loaded by Excel. I have a "runtime error '9' : Subscript out of range" just by trying to access one COM object.
I work on Windows 10 / VS 2022, Excel 2016 32 bits right now. I added a reference to nuget ExcelDNA.Addin 1.6 to my project.
My legacy target is .NET framework 4.6 x86/x64. We also aim later for .NET 6.
For these reason and some other reasons I am forced to build with dotnet build.
I found that the xll generation is done with the ExcelDna.AddIn.Tasks.dll which is located under
$(ExcelDnaTasksPath) which partially expands to
- $(ExcelDnaToolsPath)net6.0-windows7.0 for 'dotnet build' according to the MSBuildRuntimeType 'Core'
- $(ExcelDnaToolsPath)net452 for 'msbuild' (MSBuildRuntimeType == 'Full')
My question is : Why is the chosen ExcelDna.Addin.Tasks dll the one in the path net6.0-windows7.0 while my target is .NET framework?
Is there something I can do to fix the xll generation and packing in my project ?
I made a try with Excel DNA 1.7-rc 4 but there is more work than I expected. And as we target production I feel not confident to go with a release candidate.
Can you explain the problems you had with v1.7-rc4? This version might support your scenario better than 1.6.
To partly answer your question, the build task is code that runs in the build process, and that is independent of the runtime that is being targeted. So if your build process is running under a .NET core runtime, the matching .NET 6 version of the Excel-DNA builds tasks must run. MSBuild running on .NET core can target both .NET Framework and .NET 6, and vice versa.
Anyway, the Excel-DNA support for running under "dotnet build" is fairly new and has probably improved since v 1.6, so you should try the newest version. If there are problems with the current pre-release, please let me know and I can have a look.
I have native dependencies, I have done some work to build 2 separate XLLs, one for x86 and one for x64, like this ugly stuff:
<PropertyGroup Condition=" '$(Platform)' == 'x86' ">
<ExcelDnaCreate32BitAddIn>true</ExcelDnaCreate32BitAddIn>
<ExcelDnaCreate64BitAddIn>false</ExcelDnaCreate64BitAddIn>
</PropertyGroup>
<PropertyGroup Condition=" '$(Platform)' == 'x64' ">
<ExcelDnaCreate32BitAddIn>false</ExcelDnaCreate32BitAddIn>
<ExcelDnaCreate64BitAddIn>true</ExcelDnaCreate64BitAddIn>
</PropertyGroup>
And some custom copies after that in postbuild...
I have not investigated long enough for the last reason of my previous post: (embbed a release candidate in a production release is a bit reckless). But it looks like Excel DNA 1.7 has been thought to handle the 32/64 bits by itself, so I have to rework a few things.
Also I didn't find any documentation about the changes in version 1.7
When targeting .NET 6, the Excel-DNA version 1.7.0 uses the .deps.json file to get the right managed and native dependencies into the matching packed .xll files. It does not do this when targeting .NET Framework 4.x though (since there is no similar notion of a .deps.json). So when targeting .NET Framework 4.x you might still need those conditional properties.
But setting the platform when building the managed library can cause a bigger problem (not sure if this is true under both .NET Framework 4.x and .NET 6) which is that the resulting MyLibrary.dll is a mixed assembly and not a pure managed assembly, so I think it cannot be packed under the .NET Framework scheme. I don't know enough about how the .NET build is affected, but I think your main add-in library must be built with the "AnyCPU" platform.
Thank you for mentionning the potential issue with the platform setting and the resulting mixed assembly.
Somehow targeting AnyCPU for the add-in libraries seems to have fixed my main issue.
It looks like building with MSBuild or dotnet build both give a sane xll which can be at least loaded in a x86 Excel.
Thanks again.