RSTAB 9: gRPC C# client with VS Community 2022 --> Stand-alone desktop application

For several days I have been trying to create a stand-alone desktop application (C# with VS Community 2022) to communicate with RSTAB 9.

Unfortunately, the application goes into a kind of deadlock after creating an Application object via:

RSTABApp = new ApplicationRSTAB(…);

This is, of course, inside a try-catch-finally block.

If the apiKeyValue is omitted, the application correctly jumps to the exception handling in the catch part.

If the apiKeyValue is used again, a deadlock occurs after the above line and the application no longer responds.

However, RSTAB is correctly blocked:

Image

After that, I tried it with Python:

The script:

from dlubal.api import RSTAB

with RSTAB.Application(api_key_value='ak-…') as RSTAB_app:


# Retrieve the App Info

app_Info = RSTAB_app.get_application_info()

print(f"Version:\n{app_Info.name}")

works perfectly.

Now the same functionality as a C# console application:

using System;

using Dlubal.Api.Common;

using Dlubal.Api.RSTAB;

using Google.Protobuf;

using Google.Protobuf.WellKnownTypes;

using RSTAB = Dlubal.Api.RSTAB;



ApplicationRSTAB? RSTABApp = null;



try

{

RSTABApp = new ApplicationRSTAB(apiKeyValue: "ak-…");

ApplicationInfo applicationInfo = await RSTABApp.get_application_info();

Console.WriteLine("Version: " + applicationInfo.Name);



if (RSTABApp != null)

{

Console.WriteLine("Running ...");

}

else

{

Console.WriteLine("NOT running!");

}

}

catch (Exception ex)

{

Console.WriteLine($"Error: {ex.Message}");

}

finally

{

if (RSTABApp != null) await RSTABApp.close_connection();

}

Console.WriteLine("\nFinished.");

This also works without problems.

After converting the console application into a desktop application (WinExe) or into a library (DLL) with the same RSTAB API code,

the application goes into a deadlock after

RSTABApp = new ApplicationRSTAB(apiKeyValue: "ak-…");

and no further line is executed.

Is this problem known? Can you help me with this?

Thank you very much.

M. Beck, Novum Structures GmbH

Hi mbeck,

We’ve already identified this issue as well. It occurs when asynchronous methods, like CheckConnection(), are used on the UI thread. The root cause stems from the API's handling of multi-threading, especially in environments like WPF.

The goal is to enhance multi-threading support, which will help eliminate deadlocks and ensure a smoother, more reliable experience for users building multi-threaded applications.

I expect the solution to be available within the next a few weeks. I’ll keep you updated as soon as we have more details.

Sorry for any inconvenience this may cause, and thank you for your patience!

1 Like

Thank you for the quick answer.

Martin

Hello Mr. Pail,

Are there any updates on this?

With the latest RSTAB 9 version 9.13.0001 and the corresponding Dlubal.Api 2.13.1, the stand-alone application unfortunately still does not work.

Best regards,

M. Beck

Hello Mr. Beck,

We are currently testing the C# client without the async approach. Since this is a breaking change, we need to ensure that everything is thoroughly validated. Therefore, this is expected to be included in the next version 2.13.2 or 2.13.3.

Best regards,