Closed codeputer closed 6 months ago
Using the sample project from the repo, I made two changes. changed the project to .Net8, and updated the Microsoft.Azure.Devices.Client library from 1.41.2 to 1.42.2 - and it broke the RegisterAsync() method - MQTT Socket Closed after about 40 seconds. Change it back to 1.41.2, and it worked
Need help on this one as its a production issue for me - will try to work around by downgrading my application.
This is likely a dup of #3413. The latest dotnetty library has some compatibility issues with .NET 8 that we are aware of and are working on
Closing as dup
Oh good...that took three days out of my life. Client not happy with the instability.
R
Get Outlook for Androidhttps://aka.ms/AAb9ysg
From: Tim Taylor @.> Sent: Monday, March 11, 2024 11:47:43 AM To: Azure/azure-iot-sdk-csharp @.> Cc: Richard Reukema @.>; Author @.> Subject: Re: [Azure/azure-iot-sdk-csharp] MQTT Channel is Closed / Migrating Sample to .net8 caused an issue (Issue #3440)
Closed #3440https://github.com/Azure/azure-iot-sdk-csharp/issues/3440 as completed.
— Reply to this email directly, view it on GitHubhttps://github.com/Azure/azure-iot-sdk-csharp/issues/3440#event-12078513197, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAEVJVM7YLWKG2OTZE3WQM3YXYC57AVCNFSM6AAAAABEN3NDLKVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJSGA3TQNJRGMYTSNY. You are receiving this because you authored the thread.Message ID: @.***>
See attached screen shot of the repo that I'm using.
i did have some stable code, running for at least 8 months, in which I was using DPS (ProvisioningClient) to provision an IOT device. when I upgraded to .Net8, my testing revealed an error.
I got this sample working as is (.net6) , but used my DPS and IOT service credentials. Then I upgraded the transport and the provisioning client to current versions, and .Net8, and got the following error without any other changes made to the repo.
I then downgraded to versions in this repo (not sure which NUGET, as I ran out of time) the error disappeared!
Following is a more detailed shot the call stack and error generated - it takes at least 40 seconds or so before it fails.
I'm on production issue, and I'm now rolling back to get this working.