MQTTnet targeting .NET SW 4.6.1 has many dependencies

[KarloX2]

Hi!

I read issue #80 but I'm still not sure if I get this right. Foremost, I must admit I have no deep understanding of how .NET Standard / Core really works.

I target .NET Framework 4.6.1 and by installing MQTTNet via NuGet it comes up with a long list of dependencies, amongst which are animals like "System.Console.dll" and "System.Net.Sockets.dll" that seem to implement things that are already contained in FW 4.6.1, at least very similar.

First of all: What exactly is this? It must be related to .NET Standard somehow, but AFAIK ".NET Standard" is just a set of rules, not an implementation. I somewhere read that .NET FW 4.6.1 is an implementation of that standard up to some version number. So are these new assemblies then part of .NET Core?

And secondly: Do I really need all this?

Thanks!

[chkr1011]

In my opinion this is correct. We specified that only for .NET 4.5.2 the .net framework shall be used in the nuget package. For other (higher) version the .net standard is used and thus several libraries are included because Microsoft has split the .NET framework into lots of separate libraries.

But I get your concern. We will review the nuget package definition.

@JanEggers I assume we have to add every version of the .net framework (like 4.6, 4.6.1, 4.6.2 etc.) in the nuget package and use the binary from 4.5.2. Do you think this is a suitable way?

[JanEggers]

im just creating a new net461 console app to verify what is wrong first

[JanEggers]

@chkr1011 i cannot figure it out i added net461 to mqttnet.netstandard and testapp but still there are some more dlls in the testapp output of net461.

so i added a issue to dotnetstandard so maybe they can shed some light on why this is happening: https://github.com/dotnet/standard/issues/580

net452 is 1.4 MB and net462 is 2.2 MB.

@KarloX2 what are you concerned about when taking this dependencies?

- if you zip that folder its 900 KB more for deployment
- you fear the packages are not maintained? 

+ the packages are all maintained by microsoft.
+ support for dependency injection
+ common logging abstraction with a whole ecosystem to log to console / file / eventlog / db / whatever

for me the good parts outweight the bad parts.

[KarloX2]

@JanEggers my biggest concern is that there are things going on with all that libs that I don't understand.

Personally I wouldn't care too much, but in the project team there are people who will ask questions about why suddenly there's a need to put so many elements on top of the existing .Net FW.

Can you answer me this question: Where do all the additional libs come from? Is that all part of .NET Core and am I using .NET Core - or parts of it - now in top of .NET FW 4.61? Thanks!

[JanEggers]

Where do all the additional libs come from?

When we target netstandard 1.3 we have to add some nuget packages because some apis required for TLS (SSLStream and Certificate handling) that are not part of netstandard 1.3.

for the difference see:

https://github.com/chkr1011/MQTTnet/blob/0844abd7e568fd38ffa5464d964b5e089b53abe2/Build/MQTTnet.nuspec#L20-L29

compared to

https://github.com/chkr1011/MQTTnet/blob/0844abd7e568fd38ffa5464d964b5e089b53abe2/Build/MQTTnet.nuspec#L49-L53

for some reason these dlls (that should be used for netstandard1.3) are included when referencing from a net461 project. that is why i created the issue in the netstandard repository.

Also i had similar discussions in my team and i was able to make things clear with one change. if possible you can use "sdk based csproj from vs2017". the transition can be made by deleting the old project files and adding them back as .netcoreapp/.netstandard.dll and changing the targetframework to net461.

that change has some super usefull benifits:

1. dependencies are visualized as treeview and not a flat list improving the overview

2. you only have to add a dependency once. So if you have a solution with 20 projects and add mqtt to the lowest package in the dependency tree all other projects get that dependency automaticly. you dont have to add them over and over again like with the old format.

3. no more adding files to csproj everything in the folder is part of the project. that really reduced merge conflicts

[JanEggers]

i downgraded the dependencies. our internal build still copies more dlls than intended. but once it is packaged up as nuget things look better now.

here is the bin folder i got with the changes when importing the package as nuget:

[chkr1011]

I was wondering why my PC runs out of disk space. After running a tool I found why:

This is very much and I am wondering why it is such a big package. Does anyone know more?

[JanEggers]

i dont know whats in that folder? the binaries themself should not be more than 5 MB total.

[KarloX2]

@chkr1011 Hi Christian. What's the name of that tool? Thanks

[chkr1011]

@KarloX2 It is called TreeSize...

This issue is fixed in the preview version 2.5.2-rc1 (available as nuget). Please let me know if the issue is now fixed.

[KarloX2]

Hi. I've tried with 2.5.2-rc1 from scratch. Works fine now. As far as I'm concerned, this issues can be closed.

Thanks for the good work!