Tons of new dependencies when updating to v3 on .net 4.6.2

[xt0rted]

I was just updating from 1.8.5 to 3.0.0 and there's an insane amount of dependencies now for non .net core projects (I'm targeting .net 4.6.2 & 4.7 and not using anything .net core related). This is what it wants to install.

The new features for IOptions and IServiceCollection aren't needed in this setting, but they're the reason all of those extra dependencies are being pulled in.

Conditionally compiling those features for .net standard only would remove those dependencies from .net 4.5+, but I think that means anyone running .net core but targeting the full framework won't get them. I could be wrong on that, but that's my understanding of it. If that's not the case then I have a PR ready to go that conditionally compiles those features.

Another option would be two separate projects, one for .net core and one for everything else. The projects would share the same source files, but the IOptions and IServiceCollection code would be in the .net core project only. This would result in two different packages needing to be published, but it would save everyone who's not on .net core from having to deal with all of these new dependencies.

For now I'm sticking to 2.1.0 since that doesn't have all of these extra dependencies.

[ctolkien]

Sup @xt0rted , fancy seeing you here...

The new features for IOptions and IServiceCollection aren't needed in this setting, but they're the reason all of those extra dependencies are being pulled in.

I assume you're not running on MVC Core - and hence aren't using the DI/Options system to configure MailChimp?

Conditionally compiling those features for .net standard only would remove those dependencies from .net 4.5+

Wouldn't the solution be a base MailChimp package, and then a MailChimp.MvcCore layered on top?

I don't think it's an issue of FullFramework vs NetCore - given that you can also run MvcCore on FullFramework.

[xt0rted]

I'm running classic asp.net, but my mailchimp integration is in a console app and runs as a webjob.

My knowledge of .net/mvc core is very little right now, but if you setup a .net core based console app (which is possible based on what I've seen in the webjobs sdk repo) then the IOptions stuff would be relevant to those users, I assume.

Moving this stuff to an AspNetCore package is what I was initially thinking, since that's what I've seen elsewhere. But again, I haven't touched this until now and so much has changed from 1.x to 2.x that I can't really say one way or the other what needs to be done so it'll work in all situations. I just know what needs to change to work in my situation 😉

[ctolkien]

then the IOptions stuff would be relevant to those users, I assume.

Not directly. You can technically use the IOptions/DI bits in other types of apps (presumably in full framework apps as well), but a bog standard console app isn't built around those concepts in the same way the MvcCore is - in a highly opinionated way.

Also relevant is this:
#264

So there is already supposed to be a Core package ("Core" as in "bare bones", not ".Net Core").

Edit: No, that package is made by someone else.....

[brandonseydel]

Can you pull latest prerelease and let me know how it works out.

[xt0rted]

I just pulled in the 3.1.1-alpha release and all the .net core packages coming in has been resolved. The only problem now, which @ctolkien's update addressed, is for anyone running on asp.net core against the full framework they won't have the new IOptions and DI features.

[github-actions]

Stale issue message