.NET SDK v25.2.0 and 26.0.0 freeze/lock IIS/VS

Questions
21

@pauld

In regards to the sample application code and why the code is freezing. This is because the DotNet-Framework v4.8 has an issue with the synchronization context that needs an intermediate Task to generate a new context to handle exceptions.

When wait() is called on the main thread, the work inside the async function is executed on the same main thread. As a result, there is no available main thread to catch an exception. To address this, you can utilize another task, Task.Run() to encapsulate the work. This way, the responsibility will be shifted to the new Task context.

This line can be updated as so, and it should fix the code from freezing up
Task.Run(RetrieveLocationsAsync).Wait();

Itā€™s also important to note that .NET Core does not have a synchronization context, so you wonā€™t encounter this deadlock issue with .NET Core.

Let me know if you have further questions or if that is not working

22

Hey @Jordan-Square
You can replace the call with any method, not just an asynchronous call. No method using the API works with. NET 4.8.
Is the API only supporting. NET core going forward? Surely the API itself can wrap methods accordingly so the library supports. NET 4.8?

23

Itā€™s been months since Iā€™ve had a chance to look at this after my previous posts in July. I see that @Jordan-Square has blamed .NET 4.8 on the freezing problem and suggested a workaround using a second Task context. My code has no asynchronous component to it at all, so I had to jump through a number of hoops to add some obfuscation to my code. I went from this simple line:

CreateOrderResponse response = ordersApi.CreateOrder( createOrderRequest );

to this:

Task responseTask = Task.Run( async () => await ordersApi.CreateOrderAsync( createOrderRequest ) );
CreateOrderResponse response = responseTask.Result;

The workaround actually works so Iā€™m not complaining too much. Thanks for the explanation - that helped me figure out what I needed to implement.

However, I have to agree with @pauld. How is it that youā€™ve gone from 25.2.0 to 33.0.0 and the SDK is still broken?

24

Hey @dseib @pauld,

Iā€™m glad the work around is currently functioning for you, but I do agree this is unacceptable.

Apologies for the delayed reply, but I have good news! I took this feedback to our SDK team once again, and was able to secure effort towards implementing a fix. Iā€™ve just been informed that we have a fix for this, and I will update this thread when that fix is released.

Thank you for your patience on this, and continually giving feedback! :slight_smile:

EDIT: Expecting the fix will go out some time after the holidays in January

1 Like
25

@Jordan-Square thatā€™s great news, thank you! We havenā€™t been able to update the SDK in a while as we have so many integration points so this will make things much easier for us :slight_smile:

26

@pauld @dseib

Happy to let you know that the fix for this issue went out with our latest SDK release yesterday. More information here

Please consider upgrading to this version of the SDK and let me know if you run into any other troubles!

27

I know this is going back a couple of months but thanks for getting this updated. I have had to explain to my client that I could not update NuGet Packages for Square for some time. I just tested multiple points in my clientā€™s custom ERP system to make sure everything works with the new SDK update.

Regards,
Rick

1 Like