Excel doesn't start RTD

[Sprayer2708]

I think this might not be the right place to ask, but here goes:

We've written an Excel add in using Excel-DNA. Recently, I had to do some major refactoring work on it, and merging it required juggling of different branches containing fixes and file movements... it was horrific.
After about two days work, I did the smoke test and the add in started and the ribbon loaded, but calling any UDF from the add in resulted in Excel returning #N/A.

So, to analyse the issue I first tried debugging it and noticed that our constructor of the RTD server is no longer reached. All our UDF are RTD functions.

Just for completeness: the UDF code runs through until the call to XlCall.Excel(XlCall.xlfRtd, ...) but that call of course always returns ExcelErrorNA.
Next, I tried rolling back to the last version I know worked, same issue.

I tried on a different environment; here the add in ran both before and after the refactor.

To disclose everything I suspect might be the issue, I am concurrently working on rewriting said add in as a web add in using the current JS API on the same environment. I did clear the add in cache using the trust centre before testing the Excel-DNA add in.

Does anyone know of a setting in excel which may cause this behavior?

I believe there is nothing I changed about the output and its permissions that may cause this.
The .xll is still in a trusted location,
all checkmarks in the Trust Center -> Add-ins are unchecked,

when running the addin in debug mode, it appears in Excel Options -> Add-ins

[Govert van Drimmelen]

> I think this might not be the right place to ask, but here goes:

> We've written an Excel add in using Excel-DNA.

This is definitely the best place to ask :-)

I would suggest setting up a fresh project with an RTD server, to see if you can get that to work.

I suggest his one: Samples/RtdClocks/RtdClock-ExcelRtdServer at master · Excel-DNA/Samples

 

Check the setting “Application.RTD.ThrottleInterval” on your Excel (in the VBA Immediate windows is easiest). The default is “2000” (ms), which is a good value. 500 is fine as well. Just make sure it’s sensible.

 

I can’t tell from the message whether you are depending on the Excel-DNA code to do the just-in-time registration, or whether you are registering the .xll as a COM server ‘persistently’ (maybe with a call to ComServer.Register…() or running regsvr32 against the .xll) and then doing your own UDF wrapper which calls xlfRtd.

If it’s the latter, then you can simplify the test already by calling =RTD(…) from the sheet. Anyway you can inspect the registry to check the registration.

If you’re using the Excel-DNA just-in-time registration, you have to be careful with attributes on the class and also on the AssemblyInfo.cs (For example, an [assembly:ComVisible(true)] might have been removed or lost in your refactoring.)

You’re also not saying whether you are moving from .NET Framework to .NET core, which can have its own quirks.

 

If you want some more direct help, you’re welcome to send me an email.

 

Regards,

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 visit https://groups.google.com/d/msgid/exceldna/e17ba5c5-164c-4cc0-b941-8373e27aee73n%40googlegroups.com.

[Sprayer2708]

Hi Govert,

>   This is definitely the best place to ask :-)

Glad to read that!

>   I would suggest setting up a fresh project with an RTD server, to see if you can get that to work.

I assumed this wasn't needed since our addin still worked on other environments, some of which have the same OS + Excel as my dev environment. But I tried it and the RtdClocks works on my environment. 🤯

>  Check the setting “Application.RTD.ThrottleInterval” on your Excel (in the VBA Immediate windows is easiest). The default is “2000” (ms), which is a good value. 500 is fine as well. Just make sure it’s sensible.

yes, it's set to 500. We ship our AddIn together with a configurator that allows users to change config and also to change the registry values for activation of our addin and  RTD.ThrottleInterval .

>  I can’t tell from the message whether you are depending on the Excel-DNA code to do the just-in-time registration, or whether you are registering the .xll as a COM server ‘persistently’ (maybe with a call to ComServer.Register…() or running regsvr32 against the .xll) and then doing your own UDF wrapper which calls xlfRtd.

We're not explicitly registering the RTD server ourselves, so I'm assuming we're using the just-in-time registration of Excel-DNA

>  If you’re using the Excel-DNA just-in-time registration, you have to be careful with attributes on the class and also on the AssemblyInfo.cs (For example, an [assembly:ComVisible(true)] might have been removed or lost in your refactoring.)

our server definition starts like this, it didn't change. If it did, I'd assume it'd stop working on other environments?

   [ComVisible(true)]
   [ProgId(RtdServer.ServerProgId)] //ServerProgId is a const defined in the class, I don't know why it's accessed like that here
   public class RtdServer : ExcelRtdServer

>  You’re also not saying whether you are moving from .NET Framework to .NET core, which can have its own quirks.

We didn't migrate, we wrote the AddIn targeting net8.0-windows and to my knowledge, that never changed. We did switch to a newer version of Excel-DNA at some point, though. On that note, a big thank you for your continued work on it!

Our current dependencies to Excel-DNA are ExcelDna.AddIn 1.9.0, ExcelDna.IntelliSense 1.9.0 and ExcelDna.Interop 15.0.1

After seeing RtdClocks working, I checked what the differences to our AddIn are. Quickly found that the RTD call in the clocks app is not XlCall.Excel(XlCall.xlfRtd, ...) but rather XlCall.RTD().

We could use that function instead, but that'd require us to rewrite parts of our code to handle array arguments from our UDF. And also overkill if it's actually just my dev environment that is affected. Should this be caused by a setting in Excel that is commonly set though, then we'd have to reevaluate that.

[Sprayer2708]

forgot to add: I tried the RtdClocks on my environment withe the call changed to XlCall.Excel(XlCall.xlfRtd,...) and got #N/A in excel as well