I properly set TA_BOTH_DLL=TRUE and included the 64-bit DLLs and this works fine during object creation (snippet below), but… only in “debug” mode in VB.NET! As soon as I try to run the compiled “app” (in my case an XLL: Excel add-in), it falls over at the bold line below… Any suggestions?
#If TA_BOTH_DLL Then
handle = If(IntPtr.Size = 8, Native64.TA_GetHandle(vGUID), Native.TA_GetHandle(vGUID))
#Else
handle = Native.TA_GetHandle(vGUID)
#End If
You need to include the full exception. The code is correct and works. We've tested it over the decades.
The exception you're getting tells you what is going wrong so you can fix it. So… tell me *why* it fails, not that it fails. https://wyday.com/limelm/help/faq/#useful-reports
I feel you, Wyatt. I fully understand the need for clear error reporting. However, I cannot get any more useful info from the system and was hoping that you (or others) might have come across this issue (difference between DEBUG and RUNTIME behaviour) before.
All I get at RUNTIME is the message below and no licence object:
Initialization [Error] DnaLibrary AutoOpen Error : TargetInvocationException - Exception has been thrown by the target of an invocation.
Well, I would start by adding breakpoints to your VBA code and see what error you get.
Likely wrong DLL loaded, the DLL can't be found or something in that family of errors. Add breakpoints so you can test things.
I finally managed to get a better error message:
Initialization [Error] DnaLibrary AutoOpen Invoke Error : DllNotFoundException - Unable to load DLL 'TurboActivate64.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
In my case, the main (host) application is Excel, but the licensed app is my add-in (XLL). It seems that - during RUN TIME - the TurboActivate64 dll is expected to sit in the EXCEL folder, whereas it actually lives in the folder where the ADD-IN resides. This does not appear to be a problem in DEBUG mode. Does any of that make more sense?
I had to make a similar adjustment to access TurboActivate.EXE, which also lives in the add-in folder…
'launch TurboActivate.exe to get the product key from the user Dim TAProcess As New Process TAProcess.StartInfo.FileName = Path.Combine(Path.GetDirectoryName(ExcelDna.Integration.ExcelDnaUtil.XllPath), "TurboActivate.exe") TAProcess.EnableRaisingEvents = True
Perhaps something similar is required for the DLL?
As a workaround, I am now “pre-loading” the TurboActivate64.dll from a location that I specify. This successfully prevents the TA_GetHandle() procedure from looking for it in the wrong place. I do think it may be worth giving the opportunity to specify the DLL's path in the GetHandle call.
That's a good solution.
