What’s the advantage of this over DevExpress’ own NuGet server?

[MichaelRumpler]

Are you aware of https://www.devexpress.com/Support/Center/Question/Details/T466415/devexpress-nuget-packages?

I’m using their own package source and that works fine. You still need DX installed to use any of the wizards/designers and the upgrade wizard messes up with the references, but I guess that will be the same with your approach.

[augustoproiete]

Hey @MichaelRumpler, yes I'm aware of the DevExpress NuGet feed that was recently released. @Mehul contacted me in June when @DevExpress was just getting started with the first few packages, and it's great to see it growing over time.

AFAIK, as of this writing, some packages are not yet available on DevExpress' feed, such as XAF, XtraReport, and others. That would be the main reason why this project is still relevant.

Eventually, I expect @DevExpress will have NuGet packages for everything, which would finally allow me to stop maintaining this repo and switching to their feed myself.

There's one other difference (albeit small) in that I'm creating a single NuGet package for each individual assembly, and adding only the dependencies that it needs (i.e. hard-referenced assemblies), whilst DevExpress is creating bundles of controls in each package.

My approach with the more granular packages allow you to only reference the assemblies you really need, whilst the DevExpress approach will bring assemblies that you may not need/use. That's more of a personal preference, though... I guess most people don't really care about this.

[Kesmy]

@caioproiete @MichaelRumpler The severed-dependency thing is an extremely good upside of this repo. Our app deployment size is reduced by 75-80% in some cases, and at least 50% in most cases.

In one of our projects, we were being forced to pull in ~115mb of devexpress components just to take a dependency on a single 6mb assembly.