Excel-DNA version 1.8.0

[Govert van Drimmelen]

NuGet packages for Excel-DNA v1.8.0-rc are now available.
I hope to make a final release soon, around the middle of May.

The main changes for this version are:

* Add support for .NET 7/8 and RollForward property.
* Add support for custom runtimeconfig.json file.
* Migrate Registration helpers to main assembly.
* Add admin rights check before accessing machine hive for COM registration
* Support thread-safe RTD wrappers and ExcelRtdServers
* Support LosslessObservable option for ExcelAsyncUtil.Observe
* Add simple logging configuration under .NET 6 for IntelliSense.

## GitHub Sponsors

The best way to encourage ongoing development and support of Excel-DNA is to sign up as a GitHub Sponsor. Higher tiers also provide online support sessions, where I am happy to advise or help you get unstuck with your add-in development. Thank you very much to all the existing sponsors!

I also offer more formal corporate maintenance and support agreements for those using Excel-DNA in a mission critical setting.

Public support is provided via the Excel-DNA Google group.

## .NET Runtime - Status and Recommendations

Excel-DNA v1.8.0 supports:
* .NET Framework (v4.6.2 or later), and
* .NET 6/7/8+ (v6.0.2 or later) with the 'Desktop Runtime' installed.

There is a hard limitation from the .NET Core side (for us this means .NET 6+) that different versions of .NET Core cannot load into the same process.
So, an add-in built targeting .NET 6 cannot run in the same Excel instance as an add-in targeting .NET 8, and vice versa.
(One of these could run together with add-ins targeting .NET Framework, though.)
To side-step (postpone?) dealing with this problem, Excel-DNA has previously only supported .NET 6 (in addition to .NET Framework).
This was the approach up to version 1.7.0.

With the recent release of .NET 8 as a new Long-Term-Support (LTS) version, and annual releases to continue, we need a more nuanced policy regarding the .NET core runtime support.

What seems like a reasonable approach is to give the add-in developer some options on how to deal with the versions, by:
* Allowing the add-in to target newer .NET versions
* Supporting the “RollForward” setting in the project file (basically passing this through to the .NET runtime loading code).
This will allow an add-in to specify a few options, in addition to the target runtime version:
* <RollForward>LatestMinor</RollForward> Only load if the target (major) runtime version can be loaded, loading into the current patched version.
* <RollForward>Major</RollForward> Load into a newer runtime version if it is already loaded, but load the target if no runtime loaded yet.
* <RollForward>LatestMajor</RollForward> If no runtime is loaded yet, load the newest runtime installed
The last case would allow an add-in targeting .NET 6 to work together with an add-in targeting .NET 8.
The LatestMajor policy is the default for libraries from NuGet packages under .NET Core, where a library targeting .NET 6 will load into a .NET 8 process with no problems.

Although every annual version of the .NET runtime is now a ‘major’ version, with no compatibility guarantees, it does seem like care is taken to minimize breaking changes between versions. In our experiments, the Excel-DNA code and add-in libraries work under .NET 8 without problems once the add-in runtime loader parts are adjusted.

Excel-DNA now offers enough rope for add-in developers to shoot themselves and other add-in developers in the foot. For environments with tight control over what add-ins run in Excel, there shouldn’t be problems. But for add-ins that are distributed more widely (say add-ins provided to clients for access to a company’s data or models remotely) it becomes more difficult to decide what to do. My guidance for such cases would be to stick with .NET Framework 4.x, which has no version compatibility issues, and will be stably supported for the foreseeable future.

## Other changes

I'm happy to elaborate on any of the other changes for this version - please let me know what specific items you are interested in.

-Govert

[Ashutosh Bhardwaj]

aweseome !!!

[Dan Heine]

Am running Excel-DNA version 1.8.0 and ran into a weird one - when implementing custom functions using an observer to allow computation status updates to be displayed in the cell, the  ExcelAsyncUtil.Observe function seems to return an observer just fine, but Excel never updates the value of the cell.  

This has always worked (version 1.7.0) in both Debug and Release versions.  Now, in version 1.8.0, it only works in the Debug version.  The checks for null always seem to pass and the diagnostic MessageBox pop-ups are never fired.  Any ideas as to what is going on?  Was there a breaking change I missed?  

If there is somewhere else I should post this, am happy to move it.

Thanks!

Dan

/// <summary>
/// Gets the value of a field in a deliverable.
/// </summary>
/// <param name="issueId">JIRA issue key (e.g., "GALSEC-79").</param>
/// <param name="deliverableType">Type of deliverable  Not case sensitive.</param>
/// <returns>Object used by Excel to observe changes to the output.</returns>
[ExcelFunction(Description = "Gets status of a deliverable of a particular type for a release ticket.", IsMacroType = true)]
public static object GetDeliverableStatus(
[ExcelArgument(Name = "releaseIssueId", Description = "Release ticket JIRA key.")]
string releaseIssueId,
[ExcelArgument(Name = "deliverableType", Description = "\"Risk Assessment\", \"Zones and Conduits Diagram\", \"Security Requirements\", \"Threat Model\", \"Software Composition Analysis\", \"Secure Code Review\", \"Static Application Security Testing\", \"Security Manual\", \"Security Assurance\", \"Data Dictionary\", \"PIA\", \"Supplier Contracts\", \"Lifecycle Management\", \"Audit Findings\", \"Audit and Policy Compliance\", \"Security Risk Management\", \"Security Review\".")]
string deliverableType)
{
ExcelReference caller = XlCall.Excel(XlCall.xlfCaller) as ExcelReference;
if (caller == null)
{
MessageBox.Show("Caller is null");
}
TopicList topics = new TopicList(System.Reflection.MethodBase.GetCurrentMethod().Name, caller)
{
{ nameof(GetDeliverableServer.ReleaseIssueId), DashboardWebServices.Sanitize(releaseIssueId) },
{ nameof(GetDeliverableServer.DeliverableType), DashboardWebServices.Sanitize(deliverableType) },
};

return Observe(GetServer<GetDeliverableServer>(topics));
}

/// <summary>
/// Register with Excel.
/// </summary>
/// <param name="topics"></param>
/// <param name="server"></param>
/// <returns></returns>
private static object Observe(FunctionServer server)
{
// Causes Excel to subscribe as an observer unless already subscribed.
object function = ExcelAsyncUtil.Observe(server.Topics.TopicFunctionName, server.Topics.TopicArray, () => server);
if (server.Observer == null)
{
MessageBox.Show("Observer is null");
Debug.WriteLine($"UNEXPECTED: Register {server.InstanceId} for {server.Address} has no observer.");
}
return function;
}

[Govert van Drimmelen]

Hi Dan,

Could you please repeat the test for the latest pre-release version v1.9.0-beta2 of the ExcelDna.AddIn NuGet package?

If you still see unexpected behaviour, then it would help if you can make a standalone example that I can try. Either some code with no extra dependencies, or a small project on GitHub that I can run.

We had some problems with a pre-release version of Excel where the RTD implementation was buggy. We tried to work around it, and Microsoft had made some further changes, so it's possible some side-effects remain. For example, there have been some subtle timing changes that affect your scenario. I don't have reason to think that the Excel-DNA RTD implementation is broken in the current release. But I'm happy to try to understand what you're seeing.

-Govert