Slim down dependencies by splitting out transport support into separate packages.

[adminnz]

At the moment the Micorsoft.Azure.Devices.Client nuget package includes a large number of dependencies. An new .net core (2.0) console app with Microsoft.Azure.Devices.Client produces a publish output that is 8.6MB! Taking into account that this entire project is mainly for IoT devices which normally have VERY limited bandwidth. It means deploying an updated application can be incredibly costly (try finding a cost effective way to deploy a 8.6MB app to millions of devices world wide).

Based on the type of transport a number of packages (and their secondary dependencies!) can be completely removed.

• DotNetty.Codecs.Mqtt This is only used for Mqtt transport, so if a Device is using Amqp they have the overhead of having to include Mqtt dependencies they aren't using it.
• Microsoft.Azure.Amqp This is only used for Amqp transports, so if a Device is using Mqtt they have the overhead of having to include Amqp dependencies they aren't using it.
• WindowsAzure.Storage This is only used to support the Blob upload feature, which is pretty crappy considering including WindowsAzure.Storage means your pulling in its absolutely huge secondary dependencies on Microsoft.Data.Edm, Microsoft.Data.OData, System.Spatial.

Just including the WindowsAzure.Storage and its dependencies accounts of 6.5MB of that 8.6MB total size. And its only to support 1 tiny feature. Considering you could just use HttpClient directly and build the HTTP request to the REST api, you could completely remove the WindowsAzure.Storage package.

If there were packages to support just the transports the developer wants, then the total app size can be drastically reduced.

• Microsoft.Azure.Devices.Client.Mqtt
• Microsoft.Azure.Devices.Client.Amqp
• Microsoft.Azure.Devices.Client.Http

[CIPop]

Thanks for opening this @adminnz! We agree this is not ideal and we are already exploring designs to make this possible. The approach should be similar to the new ProvisioningClient and the ProvisioningTransportHandler concept (very similar to the System.Net.Http.HttpClient design).

Furthermore I also agree with separating features that may not end up being used in all scenarios such as Upload. In my opinion, we shouldn't have a single DeviceClient but several clients, one for each feature (TelemetryClient, MethodClient, FileUploadClient, etc).

The current problem is that splitting these up may cause certain API-level changes which would be breaking changes (a major version release).

/cc @olivierbloch @tameraw

Please continue adding ideas/suggestions on this thread.

[adminnz]

That sounds like a possible solution, however with splitting up the clients you would have to ensure there is a single connection to the Iot Hub. Because like I said before, Iot devices have extremely limited bandwidth/data usage constraints.

For example, to just maintain a connection to the Iot Hub (AMQP_Tcp_Only) for a month will use ~6MB of data.

[Mikkelcv]

Regarding the WindowsAzure.Storage, since this package now is divided into smaller packages for each area (blob, queue...), like: https://www.nuget.org/packages/Microsoft.Azure.Storage.Blob I assume you only need that one. (if you do not get rid of the dependency completely)

We have a problem right now where we are not able to update our solutions to the newer packages of Microsoft.Azure.Storage.X since the IoT packages has the dependency to the old WindowsAzure.Storage.

Would be nice if it was updated Thanks Mikkel

[prmathur-microsoft]

We agree with your idea and we have a new SDK version V2 coming into play soon. We will take this request as a part of it.

[RubiaL]

Thanks for the feedback. This is currently in our backlog but do not have an ETA for this yet. Please vote on this User voice item and it can also be used for tracking our plans.

[az-iot-builder-01]

@CIPop, @adminnz, @Mikkelcv, @prmathur-microsoft, @RubiaL, thank you for your contribution to our open-sourced project! Please help us improve by filling out this 2-minute customer satisfaction survey