Builds that have important deficiencies are not having their nuget packages marked as prerelease about azure-iot-sdk-csharp HOT 4 CLOSED

@v-tbert - Please specify the issue you faced with the Microsoft.Azure.Devices package and which nuget version it was. Thanks.

from azure-iot-sdk-csharp.

This week I was doing a basic test using nuget packages of Microsoft.Azure.Devices and Microsoft.Azure.Devices.Client that opened a connection, sent a message, checked whether Iothub detected the connection, and closed the connection. I tried this 1.1.4, 1.1.5, and 1.2.0. All stated versions have bugs that prevent this basic scenario from working without tweaking various things, and IMO they should reflect that by being marked as prerelease until proven otherwise, not the other way around.

Edit:
My nuget version is 3.5.0.1484

from azure-iot-sdk-csharp.

This is the simple test code that led me to finding 6 problems with the packages mentioned above, which lead me to believe these should be marked prerelease:

https://github.com/Azure/azure-iot-sdk-csharp/issues/24

from azure-iot-sdk-csharp.

Hi @v-tbert v-tbert
I have explained the difference in behavior between the UWP lib and the .Net one in the other issue #24
We need to be clearer in the documentation here that the connectedState value is NOT to be used to determine if a device is actually connected or not. It's value differs depending on the protocol used to connect the device and it's meaning is not that the device is connected or not at the moment you query the value, but more "the device has been seen in the last X minutes" (X being the TCP idle time of Azure Load Balancer).
Difference in behavior from one target platform to another needs to be documented and we will do so, but this doesn't mean that the package should be tagged as pre-release.
We will investigate and fix the issues you have identified in other issues.
Thanks for your contribution

from azure-iot-sdk-csharp.