search

Excel-DNA / ExcelDna

Excel-DNA - Free and easy .NET for Excel. This repository contains the core Excel-DNA library.
https://excel-dna.net
zlib License
1.31k stars 276 forks source link

Can we use ILRepack for our dependencies instead of ExcelDnaPack? #429

Open wh1t3cAt1k opened 2 years ago

wh1t3cAt1k commented 2 years ago

Hi @govert !

This is a question more than a bug report, sorry if this is the wrong place to ask.

Currently we use ExcelDnaPack to pack everything into the XLL including our dependencies.

What we don't like about this process is the fact that we have to separately maintain the list of deps as <Reference>s in our .dna file (with Pack="true").

I wonder if we could work around this by packing everything into our dll first using ILRepack, and then just referencing that as a single <ExternalLibrary> in the <DnaLibrary>.

govert commented 2 years ago

Hi @wh1t3cAt1k - I think it should work fine to make a single large assembly that you set as the <ExternalLibrary> The one downside I can see is that Excel-DNA scans through all the types in the ExternalLibrary assemblies to look for exports, ribbons etc. So if you have lots of extra types pulled in from the dependencies, your load time might increase a bit. You can certainly experiment with this.

What is the difficulty for you in setting up the <Reference ..> list? Do your dependencies change often?

In the new v1.6.0 previews we have done most of the work to support <PackageReference>, so that you don't need a .dna file in your project anymore - it can be generated from defaults and properties in the .csproj file. I have yet to document this, but one bit there is an <ExcelDnaReferences> property where you can add a list of files for which <Reference> tags should be generated. I'm not sure whether we support wildcards there, but having some idea of how it would work best for your projects would be interesting.

wh1t3cAt1k commented 2 years ago

Hi @govert , our deps change several times a year, I would say.

My main rationale is that it's just another potential failure point - we exploded a couple of times when a build was working fine under debug, but in release mode (the only configuration where we enable packing) we discovered a little bit too late (sometimes "deeply at runtime") that something was forgotten in .dna. I'm constantly having background anxiety about forgetting to pack something and not catching it during pre-release testing :)

So I would prefer to just have one central point of managing all the dependencies - and it seems that ILRepack takes care of merging in all your package references automagically.

Off-topic: regarding your comment about optional .dna files, where would CustomUI element go in our case in 1.6.0?

govert commented 2 years ago

With 1.6.0 you could still have a .dna file (then one is not generated from the .csproj properties). But I want to deprecate having CustomUI in the .dna file - I think it should rather go in code or as a resource in your own assembly.

wh1t3cAt1k commented 2 years ago

We don't mind moving it wherever, as long as it's supported in any way :)

govert commented 2 years ago

The one problem with packing "all .dll files in the output directory that are not ExternalLibrary files" is that there may be native or mixed assemblies which cannot be packed. Do you have such a problem, or do you always just pack every .dll in the output?

garethhayter commented 2 years ago

@Pavel I actually pack all my assemblies into a single DLL, then reference this in the .dna file. I do this as part of my automated build process. I don’t see any value adding this step to Excel DNA, seeing as I prefer fine-grained control over everything. What value do you see in Excel DNA automating this?

From: Govert van Drimmelen @.> Sent: Friday, 11 February 2022 8:08 am To: Excel-DNA/ExcelDna @.> Cc: Subscribed @.***> Subject: Re: [Excel-DNA/ExcelDna] Can we use ILRepack for our dependencies instead of ExcelDnaPack? (Issue #429)

The one problem with packing "all .dll files in the output directory that are not ExternalLibrary files" is that there may be native or mixed assemblies which cannot be packed. Do you have such a problem, or do you always just pack every .dll in the output?

— Reply to this email directly, view it on GitHub https://github.com/Excel-DNA/ExcelDna/issues/429#issuecomment-1035357655 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKV2GRQUR3DONFFCALJQ7LU2QEIVANCNFSM5OBI5XHA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you are subscribed to this thread. https://github.com/notifications/beacon/AAKV2GS6URBU7Q5MAW276B3U2QEIVA5CNFSM5OBI5XHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOHW3E3VY.gif Message ID: @. @.> >

wh1t3cAt1k commented 2 years ago

The one problem with packing "all .dll files in the output directory that are not ExternalLibrary files" is that there may be native or mixed assemblies which cannot be packed. Do you have such a problem, or do you always just pack every .dll in the output?

Yes, we have the sqlite native library which we don't pack for that reason.

Therefore the mechanism in ExcelDNA should probably support some sort of blacklist.

wh1t3cAt1k commented 2 years ago

@garethhayter can I ask you what tool you're using to repack your assemblies?

I am having trouble with ILRepack because the assemblies stop being loadable (perhaps because they're deeply merged in).

image

My Assembly.Load call fails, I suspect, because the assembly I'm trying to load is now part of the main assembly - worked fine with ExcelDnaPack. If I fix that issue by redirecting to the current (merged) assembly instead, Autofac container builder starts complaining about System.ValueTuple, which is also merged in, and perhaps it also tries to dynamically load it.

@govert as I understand ExcelDNA pack does not merge assemblies' IL, it only embeds them?

wh1t3cAt1k commented 2 years ago

To update everyone, I encountered great success when I used Costura.Fody instead of ILRepack.

Apparently it does the same thing as ExcelDnaPack (pack not merge) but "automagically" includes all your "CopyLocal" deps, and allows you to manage a blacklist, too:

image

I see no runtime issues and am happy with the result. Seems like it's pretty fast, too, it has some sort of caching for compressed assemblies that are being embedded.