Using ExcelAsyncUtil.Observe with Windows 10 and Excel 2016 - Dispose is Never Called on CancellationDisposable

[Damon Wilder Carr]

All,

I have an interesting issue. We're updating our desktops to Windows 10 with Excel 2016. During testing for whatever reason Dispose is never being called on my CancellationDisposable class (which is part of the RxExcel class you can view here:

https://github.com/Excel-DNA/ExcelDna/blob/master/Distribution/Samples/Async/AsyncFunctions/RxExcel.cs 

Is there any known reason this might happen? Everything works on Windows 7.

I've updated to the latest Excel DNA release (NuGet packages are version 0.34.6) with no luck.

Here is how I am using the ExcelAsyncUtil.Observe call from my Excel DNA function:

            var result = ExcelAsyncUtil.Observe("QRDE", new[] { referenceString, functionName, arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8, arg9,

                arg10, arg11, arg12, arg13, arg14, arg15, arg16, arg17, arg18, arg19, arg20 }, delegate

            {

                Func<CancellationToken, Task<object>> taskSource =

                    token => PTXLAsync(caller, functionName, arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8, arg9, arg10, arg11, arg12, arg13, arg14, 

                    arg15, arg16, arg17, arg18, arg19, arg20, token);

                

                var cts = new CancellationTokenSource();

                cancellationTokens.AddTokenSource(cts);

                var task = taskSource(cts.Token);

                return new ExcelObservable<object>(task.ToObservable());

            });

The above is after updating my code to instantiate an ExcelObservable - here is how the code was previously using an older version of sample code (same result - Dispose is not called).

            var result = ExcelAsyncUtil.Observe("QRDE", new[] { referenceString, functionName, arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8, arg9,

                arg10, arg11, arg12, arg13, arg14, arg15, arg16, arg17, arg18, arg19, arg20 }, delegate

            {

                Func<CancellationToken, Task<object>> taskSource =

                    token => PTXLAsync(caller, functionName, arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8, arg9, arg10, arg11, arg12, arg13, arg14, 

                    arg15, arg16, arg17, arg18, arg19, arg20, token);

                

                var cts = new CancellationTokenSource();

                cancellationTokens.AddTokenSource(cts);

                var task = taskSource(cts.Token);

                return new ExcelTaskUtil.ExcelTaskObservable<object>(task, cts);

            });

I need dispose to be called so the cancellation token source is cancelled. I have logic that keeps track of pending operations and this is how I know what is pending. For more info this is never running:

In CancellationDisposable:

        public void Dispose()

        {

            cts.Cancel();

        }

Thanks,

Damon Carr

[Govert van Drimmelen]

What is your exact Excel version?

-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 post to this group, send email to exce...@googlegroups.com.
Visit this group at https://groups.google.com/group/exceldna.
For more options, visit https://groups.google.com/d/optout.

[Damon Wilder Carr]

I'm seeing this issue with Excel 2016 16.0.8201.2193 (64-Bit)

Things work fine on Excel 14.0.7188.5002 (32-bit)

Thanks,

Damon

[Damon Wilder Carr]

There is another change in behavior i am seeing between the different Excel versions related to the use of the ExcelAsyncUtil.Observe method. Previously I would have cases where the result from this call was: ExcelError.ExcelErrorNA. I could often wait and refresh and the value would eventually return OK. Simply calling the ExcelAsyncUtil.Observe method again would eventually work.

Now I am seeing cases where the call to ExcelAsyncUtil.Observe will work once or twice (my breakpoint will get hit on the code inside the ExcelObservableSource delegate) and then always return ExcelError.ExcelErrorNA after that no matter what.

I'm wondering if the issues are related - the fact that the disposable object that is returned from the Subscribe method on the IExcelObservable is never disposed (which was my initial observation in this thread).

On Thursday, November 30, 2017 at 7:49:50 PM UTC-8, Govert van Drimmelen wrote:

[Govert van Drimmelen]

OK - I want to start with an example that we can both run and test.

Then we can see where the unexpected behaviour arises - Excel, Excel-DNA, the RxExcel helper or your code.

Could you:

* Create a new Class Library project

* Install the ExcelDna.AddIn NuGet package

* Insert the code from https://gist.github.com/govert/99b13368b1c1e78a5c9c77e43052f8ae

Press F5 to load in Excel - you should get you a function called TestObservable taking one string parameter.

You can monitor the create and dispose calls in the Debug window.

I am testing under 32-bit Excel version 16.0.8625.2121.

Everything seems to work as I expect.

In particular, if I call the function and the delete it from the cell, Dispose gets called, and if I have the function getting the input parameter from another cell, changing that cell (and hence the parameter) causes a new topic to be created, and Dispose to be called on the old one.

Can you try this and confirm whether you get it to run, and what you see?

-Govert

[Damon Wilder Carr]

Excellent idea. Very interesting result.

Indeed it fails on 64-bit excel with #N/A. Crazy!  It actually hits the TestObservable function fine in the debugger - however it never hits the constructor for ExcelObservableClock. The ExcelAsyncUtil.Observe just immediately fails.

I've tested it with no debugger attached as well - same issue.

Just to be sure I tested this on 32-bit Excel (but Excel 2010) and it worked perfectly.

So.... It would appear there is an issue with Excel 64-bit. I'm trying to get a VM Setup with the 32-bit version of Excel 2016 just to verify. If that works at least I have a fallback plan.

[Govert van Drimmelen]

I think that's what you'll see in 'Manual' calculation mode too ...

-Govert

[Govert van Drimmelen]

Hi Damon,

OK, I've tried the same sample on 64-bit Excel v 16.0.8730.2046 and everything seems fine.

It looks like the problem is on your side.

Regards,

Govert

[Damon Wilder Carr]

Huh. Strange. Would it be possible for you to email me your full Visual Studio Project or upload it somewhere I can try it? My email is damon.carr at pimco.com

I created the project using VS 2015 targeting .NET 4.5 and 'Any CPU' and verified it worked on Windows 7 - 32 but Excel. I then copied the project over to the Windows 10 box and compiled it using Visual Studio 2017. Perhaps I am doing something wrong in how I created the project? 

On the failed Windows 10 box I tried targeting .NET 4.61 but that had no effect. The Excel version you mentioned is working for you on 64-bit is an older version than I have, but I doubt that would be the issue.

Any ideas what would cause a complete failure of this? Permissions perhaps? Do I need to explicitly compile for x64 instead of 'Any CPU'?

Thanks,

Damon

[Damon Wilder Carr]

A little more info - the debugger does break in the timer_tick method - however the _observer instance is always null. It seems the Subscribe method is never called on ExcelObservableClock. Also I just noticed your Excel version is also actually newer than mine so I'm going to see if I can upgrade and see if that is the issue. I also tried compiling 'x64' instead of 'Any CPU' and it had no impact. 

[Damon Wilder Carr]

I even tried using the 64-bit versions of the .XLL (packed and non-packed) compiled on the Windows 7 box just to exclude any weirdness with Visual Studio 2017 - same result - immediate #N/A on the call.

[Damon Wilder Carr]

We finally figured this out. We had to digitally sign our add-ins due to organizational security requirements.

Once we digitally signed our add-ins they worked great on Excel 2016 64-bit on Excel 16.0.8625.2121 with RTD.

[EL2]

How did you digitally sign your addins?  I need to do the same...

[Andrew Knight]

A post build step:  in project Properties > Build Events > post build step

"C:\Program Files (x86)\Microsoft SDKs\ClickOnce\SignTool\signtool.exe" sign /f "$(ProjectDir)Codesigning.pfx" /p pwd@M "$(TargetDir)a-AddIn-packed.xll"  

"C:\Program Files (x86)\Microsoft SDKs\ClickOnce\SignTool\signtool.exe" sign /f "$(ProjectDir)Codesigning.pfx" /p pwd@M "$(TargetDir)a-AddIn.xll"  

"C:\Program Files (x86)\Microsoft SDKs\ClickOnce\SignTool\signtool.exe" sign /f "$(ProjectDir)Codesigning.pfx" /p pwd@M "$(TargetDir)a-AddIn64-packed.xll"  

"C:\Program Files (x86)\Microsoft SDKs\ClickOnce\SignTool\signtool.exe" sign /f "$(ProjectDir)Codesigning.pfx" /p pwd@M "$(TargetDir)a-AddIn64.xll"  

"C:\Program Files (x86)\Microsoft SDKs\ClickOnce\SignTool\signtool.exe" sign /f "$(ProjectDir)Codesigning.pfx" /p pwd@M "$(TargetPath)"  

Use a Code Signing Certificate from either your Company domain (for internal staff) or a trusted RCA for public consumption, if its just for your machine then a locally generated VS certificate would do the trick, if you install the certificate into Trusted Cert Authorities path in Certificate Manager.