Excel-DNA 1.6 - .NET 6 / PackageReference / Anti-virus
Govert van Drimmelen
The extension libraries ExcelDna.Registration and ExcelDna.IntelliSense also have matching releases.
ExcelDnaDoc should follow in the coming weeks.
The main focus for version 1.6 is to provide a first preview of the support for add-ins that target .NET 6.
As a prerequisite to adding the .NET 6 target, we've also added support for new SDK-style project files and <PackageReference> NuGet references (also great for projects that target .NET Framework).
I've also taken the opportunity to tweak the Excel-DNA packing mechanism a bit in an attempt to avoid some of the false positive anti-virus detections we've seen recently.
I'll briefly discuss these (in reverse order) below, but first a word about our sponsors.
GitHub sponsors
---------------
Excel-DNA is now registered on GitHub sponsors - see https://github.com/sponsors/Excel-DNA.
Thank you very much to everyone who has already signed up - your contributions are directly funding further development.
If you use Excel-DNA and would like to encourage future support and ongoing development, please sign up as a GitHub sponsor for the project.
GitHub sponsors will also have access to a private repository of sample projects where I hope to add additional tools and documentation over time.
I had previously considered the .NET Core / .NET 6 support as a good point to switch to a commercial model for Excel-DNA.
However, the benefits of being an open-source project with a permissive license have been significant.
So, if possible, I hope to continue with the core library as free and open source software, where further development is funded by the sponsors.
For those in a corporate setting using Excel-DNA extensively or in a mission critical role, I also offer an annual corporate support agreement.
Please contact me directly if you are interested in more details.
Anti-virus false positives
--------------------------
Over the last year we've seen a number of anti-virus and security programs identify Excel-DNA add-ins as security risks, including false positive detections that delete add-in files by the default Windows Defender service.
It seems that these detections were triggered by some malicious Excel add-ins that have been built using Excel-DNA, with the anti-virus heuristics subsequently identifying all Excel-DNA add-ins as problematic.
For some security vendors, including Microsoft, we've been able to report this false positive detection and they have updated their signatures accordingly.
But in many cases the Excel-DNA version 1.5 add-ins are still being flagged.
It seems the main heuristic used to detect Excel .xll add-ins as problematic is the presence of executable assemblies as resources in the .xll library.
Excel-DNA uses the packing of assemblies as resources in the .xll to simplify the add-in distribution, in many cases making possible a single file (or two files for 32-bit and 64-bit) add-in distribution.
For this version there are two changes which may help with these false positives.
The first is that packed files are now encoded, so that they are not detected as embedded executable code directly.
In my testing that change removed the false positive detections at least in the Microsoft products.
However, at least one other user has reported still seeing problems with this version, so it does not seem like bullet-proof solution.
Another option has been contributed by user @Phundamentals (thank you!), to add a project property which disables the compression of packed files.
<ExcelDnaPackCompressResources>false</ExcelDnaPackCompressResources>
Should these mitigations not be enough to reduce most false positives, we could also introduce an option where there are no packed files at all (currently the managed Excel-DNA assemblies are always packed).
There have also been some indications that signing the final add-in library helps reduce false positive detections.
In all cases I do encourage developers to report the false positives to their anti-virus or security vendor.
Their software is mistakenly identifying and blocking legitimate add-ins from running.
Developers of malicious add-ins are welcome to contact me for sponsored licences of an alternative add-in framework.
PackageReference and SDK-style project files
--------------------------------------------
The main ExcelDna.AddIn NuGet package now supports <PackageReference> references in SDK-style project files.
For new projects, this means that a .dna file is no longer added to the project automatically, and if not present will be created and output at build time from project properties.
Existing projects with customized .dna file(s) will work as they did before.
For a new project, a simple project file might look like this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net472</TargetFramework>
<!-- We don't need the extra 'ref' directory and reference assemblies for the Excel add-in -->
<ProduceReferenceAssembly>false</ProduceReferenceAssembly>
<!-- We need all dependencies to be copied to the output directory, as-if we are an 'application' and not a 'library'.
This property also sets the CopyLockFileAssemblies property to true. -->
<EnableDynamicLoading>true</EnableDynamicLoading>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="ExcelDna.AddIn" Version="1.6.0-preview3" />
</ItemGroup>
</Project>
Various additional properties can be set in the project file - see the example here https://github.com/Excel-DNA/ExcelDna/blob/master/Source/Tests/ExcelDna.AddIn.Tasks.IntegrationTests.TestTarget/SDKProperties/SDKProperties.csproj
.NET 6 support
--------------
Excel-DNA version 1.6 (finally!) includes support for add-ins that target .NET 6.
Most Excel-DNA features seem to work, including the COM-based features like RTD-based functions, ribbon and CTP extensions.
However, there has been very limited testing and you should consider the .NET 6 support as an early preview.
Update the TargetFramework tag in an SDK-style project file to the .NET 6 (Windows) target:
<TargetFramework>net6.0-windows</TargetFramework>
or build for both .NET Framework and .NET 6, which allows you to test both targets:
<TargetFrameworks>net472;net6.0-windows</TargetFrameworks>
End users of the add-in will need to have the .NET 6 runtime installed.
(To include the runtime files as part of the add-in will not be supported, but an installer program might check and install the runtime.)
A hard limitation of the .NET core series of runtimes (.NET 5 / 6 / 7 etc.) is that only one version of a .NET core runtime can be loaded into a specific process.
The core runtime can still be loaded concurrently with a .NET Framework runtime (e.g. .NET Framework 4.8), although this is not a configuration officially supported by Microsoft.
Excel-DNA will try to support add-ins targeting a .NET Framework running together with .NET 6 add-ins, but there is not planned to be any support for the future .NET 7 runtime.
Fortunately .NET 6 is a 'Long-term Support' (LTS) release and will be formally supported until the end of 2024, so we can keep targeting .NET 6 for a few years.
There is also some work on the horizon that make ahead-of-time compilation of .NET libraries (like the Excel-DNA add-ins) viable, bypassing the concurrent runtime issues.
So I do expect a future path beyond .NET 6, though that is not an immediate concern.
I look forward to bug reports, questions and other feedback about the .NET 6 support (including whether it works at all).
Support for modern .NET has been a long time coming and ensures that Excel-DNA can take part in the exciting future evolution of .NET.
After 16 years I am still amazed by and deeply appreciate the support and enthusiasm for Excel-DNA.
Last but not least I want to thank Sergey Vlasov for his calm and consistent efforts that are now driving the project forward.
-Govert
vincent bardin
Thanks for the latest version. I tried with .Net 6.0 (visual studio 2022). After installing ( Install-Package Excel-DNA.Lib -Version 1.6.0-preview3 ) and compiling. No .xll file was generated. Any thoughts?
Govert van Drimmelen
vincent bardin
vincent bardin
Govert van Drimmelen
<PropertyGroup>
<TargetFramework>net6.0-windows</TargetFramework>
<ProduceReferenceAssembly>false</ProduceReferenceAssembly>
<EnableDynamicLoading>true</EnableDynamicLoading>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="ExcelDna.AddIn" Version="1.6.0-preview3" />
</ItemGroup>
</Project>
vincent bardin
Gareth Hayter
Govert van Drimmelen
Hi Gareth,
Thank you for reporting this.
I don’t seem to have this problem with my Windows Defender – maybe you can add some version and other information to track things.
I don’t know whether Defender can tell which library in the Excel process is writing the temp file, so maybe you can also check whether writing to a temp file from VBA is also blocked. I’m guessing these are ongoing attempts to stop Excel malware vectors, including .xll add-ins, xlam files etc. from downloading malware to the machine.
Are you targeting .NET Framework or .NET 6 in this context?
When targeting .NET Framework, I think we would often not write any files at all. The .dna file, assemblies etc. are all loaded from memory. The one exception is the .config file – if it is embedded in the add-in, it will be written to a temp file when loading. You can prevent that by not having a config file in your project at all (maybe doing configuration from code, if possible) or by putting a .xll.config file next to the add-in. Then I think it won’t try to persist the file from resources.
When targeting .NET 6 we write some other temp files during startup. Unfortunately the .NET 6 hosting API is much less friendly and flexible than .NET Framework, and we need some extra bits. I’m not sure there is an option here other than adding an option to ship a bunch of loose files with the add-in. I hesitate to do that, because it would endanger the one real security measure we can offer add-ins, which is to cooperate with the Office signing.
I welcome any more info you can offer.
-Govert
--
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 on the web visit https://groups.google.com/d/msgid/exceldna/081a14dc-2851-4a44-9a0d-db749e642b95n%40googlegroups.com.
Gareth Hayter
Hi Govert
To clarify, it’s not Windows Defender, it’s Defender Enterprise. I’m targeting .Net Framework, not .Net 6. There is no .config file in my projects.
I found this a few days back, which makes for interesting reading: Weaponization of Excel Add-Ins Part 1: Malicious XLL Files and Agent Tesla Case Studies
This is what the user sees:
Many thanks,
Gareth.
Govert van Drimmelen
Hi Gareth,
Ah – I see there is stuff being compiled at runtime, which should be easy to avoid.
This should only happen if you have some code in the .dna file, though it might be interpreted that way by mistake.
Maybe you can post the .dna file, or go through it and see what needs to be moved around or cleaned up?
You want to get to something like this:
<?xml version="1.0" encoding="utf-8"?>
<DnaLibrary Name="My Special Add-In" RuntimeVersion="v4.0" xmlns=http://schemas.excel-dna.net/addin/2020/07/dnalibrary>
<ExternalLibrary Path="MyFunctions.dll" ExplicitExports="false" LoadFromBytes="true" Pack="true" IncludePdb="false" />
<Reference Path="Another.Library.dll" Pack="true" />
</DnaLibrary>
If you have ribbon markup in there, it should not be a problem but could easily be moved into the code.
Maybe I’m missing something.
-Govert
From: exce...@googlegroups.com <exce...@googlegroups.com> On Behalf Of Gareth Hayter
Sent: 23 March 2022 23:52
To: Excel-DNA <exce...@googlegroups.com>
Subject: Re: [ExcelDna] Re: Excel-DNA 1.6 - .NET 6 / PackageReference / Anti-virus
Hi Govert
To clarify, it’s not Windows Defender, it’s Defender Enterprise. I’m targeting .Net Framework, not .Net 6. There is no .config file in my projects.
I found this a few days back, which makes for interesting reading: Weaponization of Excel Add-Ins Part 1: Malicious XLL Files and Agent Tesla Case Studies
This is what the user sees:
To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/0db457ef-f960-4241-a402-1e121e726475n%40googlegroups.com.
Gareth Hayter
<Reference Name="System.Windows.Forms" />
<Reference Name="System.Drawing" />
<Reference AssemblyPath="XXXXXXX.dll" Pack="true" IncludePdb="true" />
<ExternalLibrary Path="XXXXXXX.dll" ExplicitExports="true" LoadFromBytes="true" Pack="true" IncludePdb="true" />
<ExternalLibrary Path="Microsoft.Office.Interop.Excel.dll" LoadFromBytes="true" Pack="true" />
<ExternalLibrary Path="Office.dll" LoadFromBytes="true" Pack="true" />
<ExternalLibrary Path="Microsoft.Vbe.Interop.dll" LoadFromBytes="true" Pack="true" />
<ExcelDnaPackCompressResources>false</ExcelDnaPackCompressResources>
<![CDATA[
using System;
using System.IO;
using System.Windows.Forms;
using ExcelDna.Integration;
using ExcelDna.Integration.CustomUI;
using ExcelDna.Integration.Extensibility;
using ExcelDna.Logging;
using XXXXXXX;
// This allows the add-in to run code at start-up and shutdown.
public class XXXXXXXAddIn : IExcelAddIn
{
private DnaStartup startup;
public void AutoOpen()
{
try
{
startup = new DnaStartup();
DnaStartup.OnAutoOpen();
}
catch (Exception ex)
{
LogDisplay.WriteLine("Error in AutoOpen: "+ ex.Message);
}
}
public void AutoClose()
{
try
{
DnaStartup.OnAutoClose();
}
catch (Exception ex)
{
LogDisplay.WriteLine("Error in AutoOpen: "+ ex.Message);
}
}
}
]]>
<Image Name="imgWarning_32" Path="warning_32.png" Pack="true" />
<Image Name="imgLighthouse_32" Path="Sheet Tabs Layout_32-px.png" Pack="true" />
<Image Name="imgShortcuts_32" Path="gear_32.png" Pack="true" />
<Image Name="imgUpdate_32" Path="internet_download_32.png" Pack="true" />
<Image Name="imgSwitch_32" Path="switch_32.png" Pack="true" />
</DnaLibrary>
=================================================================================================
Govert van Drimmelen
Hi Gareth,
There are a few things to clean up.
- I suggest you only need this in the .dna file:
<DnaLibrary Name="XXXXXXX" Description="XXXXXXX" RuntimeVersion="v4.0">
<ExternalLibrary Path="XXXXXXX.dll" ExplicitExports="true" LoadFromBytes="true" Pack="true" IncludePdb="true" />
<Image Name="imgWarning_32" Path="warning_32.png" Pack="true" />
<Image Name="imgLighthouse_32" Path="Sheet Tabs Layout_32-px.png" Pack="true" />
<Image Name="imgShortcuts_32" Path="gear_32.png" Pack="true" />
<Image Name="imgUpdate_32" Path="internet_download_32.png" Pack="true" />
<Image Name="imgSwitch_32" Path="switch_32.png" Pack="true" />
</DnaLibrary>
- Keep the packed images, they-re convenient there.
- Move the code XXXXXXXAddIn into your .dll. This is the main problem you have now. If you can’t do this easily because you can’t take a dependency on ExcelDna.Integration.dll there, you need to restructure stuff a bit.
- Don’t worry about the <ExcelDnaPackCompressResources> for now, but if you want to set it will go into the .build.properties file in your project, or the new SDK-style .csproj file if you migrate. It does nothing in the .dna file.
- If any of the COM stuff breaks when you remove those COM-related <Reference> tags, set the ‘Embed Interop Types’ option for these references in your project. Or install the ExcelDna.Interop package from NuGet.
To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/b7f057e4-e6b3-4356-a199-b34b617116c7n%40googlegroups.com.
Gareth Hayter
Gareth Hayter
Kevin Roche
<ExcelDnaPackCompressResources>false</ExcelDnaPackCompressResources>
to ExceDNA.Build.Props, but no success. Unfortunately, I'm actively updating an add-in that has been in use for a while but the company virus scanner is preventing build, not to mention getting me into trouble :-(.
Govert van Drimmelen
Hi Kevin,
Can you confirm exactly what anti-virus you are using?
Can you show any details about which files are being detected / quarantined – only the packed .xll files or the ExcelDna.Integration.dll file as well?
Have you reported the false positive to the anti-virus vendor?
We are working on an option to make a loose-files type of add-in, which means there is no packing at all, hopefully avoiding one of the common anti-virus heuristics.
That might still not help in the build environment, where the contents of the NuGet package might get blocked.
But it could help to give a distribution option in some environments.
That will be coming in the next preview version in a few weeks’ time.
To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/625bbe9d-38b1-4a96-904f-38bb0eeacf81n%40googlegroups.com.
Kevin Roche
Enable/Disable packing of .dna files
-->
<RunExcelDnaPack Condition="'$(RunExcelDnaPack)' == ''">false</RunExcelDnaPack> <- changed from True, I realise I could also provide the RunExcelDnaPack environment variable.
That seems to stop the virus detection, but obviously I don't get the packing - I think I'm OK with this for now, but if there is another solution that would be great.
Kevin Roche
Govert van Drimmelen
Hello Kevin,
I have been struggling with the CloudStrike Falcon product also, and have gone tough discussions with our security department ☹
For deployment, we have now whitelisted the xll.
Before that, Crowdstrike did not allow the copying of the xll onto our client machines.
However, since a few weeks, I found that a combination of signing the xll with our corporate certificate, and not compressing the components into the xll satifies Crowdstrike.
For not compressing, I use : ExcelDnaPack xxxxxxxxx.Dna /NoCompression
We will now remove the whitelisting and the signed, non-compressed xll can be deployed.
For development on my machine, that remains to date a nightmare.
I cant use nugent at all and need to install ExcelDNA dll’s in another way.
I had to whitelist my development folder also.
Our security department says that this is because all Excel DNA dll’s are not properly signed, which I cannot confirm.
I have gone through a nightmare in convincing our security department that ExcelDNA is ok.
But this whole virus issue is surely putting some issues around using ExcelDNA in a commercial environment – think we must resolve this…
Kind regards – please reply with your Crowdstrike experience as needed.
guido
Kevin Roche
Gareth Hayter
