Excel-DNA version 1.6 is now available for testing as pre-release version 1.6.0-preview3 from the NuGet package repository. 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 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 bulletproof 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 licenses of an alternative add-in framework.
PackageReference and SDK-style project files
The main ExcelDna.AddIn NuGet package now supports 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