Closed Chadders187 closed 8 months ago
@Chadders187 Thank you - I think this is a useful suggestion.
Looking forward to see this implemented as we also have an addin with lots of nuget packages.
As a temporary solution I created a custom msbuild task that updates .dna files to include all the necessary references:
<Target Name="ExcelDnaIncludeReferences" DependsOnTargets="ExcelDnaBuild" BeforeTargets="ExcelDnaPack">
<!-- read existing content -->
<XmlPeek XmlInputPath="%(ExcelDnaFilesToPack.OutputDnaFileName)" Query="//DnaLibrary/*">
<Output TaskParameter="Result" PropertyName="Peeked" />
</XmlPeek>
<!-- find all dependencies -->
<ItemGroup>
<ExcelDnaReferences Include="@(ReferenceCopyLocalPaths->'<Reference Path="%(Filename)%(Extension)" Pack="true" />')"
Condition="'%(Extension)' == '.dll'" />
</ItemGroup>
<!-- combine existing content with the required dependencies -->
<PropertyGroup>
<ExcelDnaReferencesXml>@(ExcelDnaReferences)</ExcelDnaReferencesXml>
<ConcatenatedNodes>$(Peeked.Replace(";",""))$(ExcelDnaReferencesXml.Replace(";",""))</ConcatenatedNodes>
</PropertyGroup>
<!-- update .dna file -->
<XmlPoke Value="$(ConcatenatedNodes)" XmlInputPath="%(ExcelDnaFilesToPack.OutputDnaFileName)" Query="//DnaLibrary">
</XmlPoke>
<Message Text="Patched %(ExcelDnaFilesToPack.OutputDnaFileName)." Importance="High" />
</Target>
@altso That's amazing!
I didn't know about XmlPeek
/ XmlPoke
before.
I had some trouble running it as is, because the default .dna files now have a namespace included, and then the XPath seems to fail. Writing the XmlPeek and XmlPoke queries this way seems to work with and without the namespace in the .dna file:
<Target Name="ExcelDnaIncludeReferences" DependsOnTargets="ExcelDnaBuild" BeforeTargets="ExcelDnaPack">
<!-- read existing content -->
<XmlPeek XmlInputPath="%(ExcelDnaFilesToPack.OutputDnaFileName)" Query="//*[local-name()="DnaLibrary"]/*" >
<Output TaskParameter="Result" PropertyName="Peeked" />
</XmlPeek>
<!-- find all dependencies -->
<ItemGroup>
<ExcelDnaReferences Include="@(ReferenceCopyLocalPaths->'<Reference Path="%(Filename)%(Extension)" Pack="true" />')"
Condition="'%(Extension)' == '.dll'" />
</ItemGroup>
<!-- combine existing content with the required dependencies -->
<PropertyGroup>
<ExcelDnaReferencesXml>@(ExcelDnaReferences)</ExcelDnaReferencesXml>
<ConcatenatedNodes>$(Peeked.Replace(";",""))$(ExcelDnaReferencesXml.Replace(";",""))</ConcatenatedNodes>
</PropertyGroup>
<!-- update .dna file -->
<XmlPoke Value="$(ConcatenatedNodes)" XmlInputPath="%(ExcelDnaFilesToPack.OutputDnaFileName)" Query="//*[local-name()="DnaLibrary"]">
</XmlPoke>
<Message Text="Patched %(ExcelDnaFilesToPack.OutputDnaFileName)." Importance="High" />
</Target>
@govert thanks for making it work with namespaces. The .dna file I had was created long time ago.
Related feature request: Allow wildcard references in .dna file
There are now additional options for including dependencies - see https://groups.google.com/g/exceldna/c/xZHE2SouxXw
As per my post on Deployment issues with NuGet packages- Help wanted, I've been having difficulty constructing an appropriate "-packed.xll" file in my project that has multiple dependencies.
To summarise, it appears that only the project code itself is being packed whilst it's dependencies are not. The solution is for me to go and add in some nodes into the .dna file. However, this is an onerous task and is not robust. For example, any changes to the dependencies, or dependencies of those dependencies, could lead to new needing to be added. I will not know this though either until after deployment of the xll file during testing, or unless I scour through the bin folder itself before deployment.
My suggestion is therefore as follows:
An additional argument added to the ExternalLibrary node for, say, "PackBuildFolderByDefault". E.g...
If true, the equivalent of "Reference Pack="true"" would be dynamically added at runtime for all of the dlls found in the project build folder.
To exclude any dlls that you may not want in the packed file, the functionality could be used and the above wouldn't dynamically be added if existing nodes were found.
Give that you already state that the mixed native/managed dlls are currently handled by excluding them. Initially, I'd expect there to be no differences here.
Let me know if you have any further thoughts.