Description
Intermittently getting an issue with “Waiting For Host” appearing; despite using the Host account to generate a ZAK and providing it to the Start method.
This issue reproduces infrequently in our much larger main application,
But was consistently occurring when using the demo application.
It appears to me there is an issue getting the proper ZAK token across the C# - C++/CLI boundary.
I wouldn’t experience the issue in the demo app when hard coding the ZAK into the following location.
Found in Meeting_service_dotnet_wrap.cpp
Start(StartParam startParam) (line 204)
startParam_c.param.withoutloginStart.userZak (Line 229)
After changing the method signature to use a Handle parameter, the issue stopped occurring as well.
Changing
SDKError CMeetingServiceDotNetWrap::Start(StartParam startParam)
to
SDKError CMeetingServiceDotNetWrap::Start(StartParam^ startParam)
I found a similar with enabling debug logs and dump generation.
That the setting chosen would at times be ignored, and no dump or debug logs generated.
Again I could hard code the values in the wrapper to be true and get the expect outcome.
But after changing within
Zoom_sdk_dotnet_wrap.cpp
Initialize(InitParam initinfo) (line 27)
to
Initialize(InitParam^ initinfo)
I now consistently produce logs and dump generation.
Can these methods and the others that take Value Classes be updated appropriately ?
Which Windows Meeting SDK version?
C# Wrappers
First noticed in SDK 5.10.1 and subsequent versions up to 5.13.5
Still noticed in 5.13.5