NuGet Packages

What about a private NuGet server that requires our DevExpress username and password (HTTP Auth)?

Hello Thomas,
The main difficulty is not in setting up a NuGet server, but in the fact that we are using an in-house made installation engine highly adapted for our needs. Moving the existing installation logic is not a quickly resolvable task. All in all, the idea itself has its merit, and we will keep it on our radar.

Hello, it's been three years since the last comment from DevExpress about this.
Any news on providing us with NuGet packages?

While we now provide NuGet packages for our DevExtreme products (see https://www.nuget.org/packages?q=DevExtreme+), we are still committed to our own installer for .NET and VCL products. This does not mean that we get rid of this idea, but I cannot give any promises at this time.

Thanks Serge. I'm currently building the packages myself for internal use at my company and would love to use an official version from DevExpress.
Anyway, there's a lot of people in the same situation that I am, so would it be OK to publish these packages on nuget.org? They would include DevExpress license file, license URL, ask the user to accept the license when installing, and they would all have the ID "Unofficial.DevExpress.*.nupkg" so it is clear that it is not built/supported by DevExpress.
Here is an example of how the NuGet packages would look like:
https://gist.github.com/CaioProiete/f79978d7fa37ea687317#file-unofficial-devexpress-xpf-docking-nuspec

Caio, I appreciate your willingness to improve our products and services. However, I'm afraid we can discuss your suggestions only at the level of our management because it involves licensing issues. Would you please email us at management@devexpress.com for further clarification?

Thanks Serge. I've just sent an e-mail to management@devexpress.com as instructed.

Even making the nuspec and/or nupkg files available for us to publish on our own internal nuget servers would be a huge plus.

BTW, It's been 3 weeks since I've sent the e-mail to management@devexpress.com, and didn't got any reply so far…

Caio, would you be willing to share your nuspecs? It would sure save me some time.

@Ben: Sure. I'd happily share the nuspecs. I'll put it on GitHub tomorrow.

Great, thanks Caio. I've bookmarked your GitHub page.

@Ben, here you go:
https://github.com/CaioProiete/DevExpress-NuGet
Hope you find it useful.

I really would appreciate also to have a NuGet-Version of your .net-libraries available. It's always a pain in the ass to install updates of your libraries, especially when one has different projects working with different minor version changes of DevExpress.

I would also like nuget packages for DevExpress as it would really help us to debug old releases.

+1 for a nuget package install - we now actively avoid using DevExpress tools in new projects because of issues associated with different versions and the installer.

I'll also submit a +1 for a **continuouos integration, remote server compatible** way to use DevExpress assemblies.  A NuGet solution is just one such idea, but any officially supported way to get DX assemblies on to my Visual Studio Online automated testing machines would be great.  Copypasting .dlls is far to fragile for me.

This feature is highly requested and with no new comments from DevExpress in years. Can we get an official update on this?

+1000. It's been a year since the last time I've asked for it… Still nothing. How hard could it be to ship NuGet packages, DevExpress? Oh wait… I know, took me **one day** to create this: https://github.com/CaioProiete/DevExpress-NuGet what is your excuse, DevExpress? :(

Is there any official update on this feature? It will greatly help our current developments

Totally agree: we need this to help us with the frequent updates and to manage different versions for different projects and for our build server and and and …

Any progress in NuGet? DevExpress do you made a decision?

It really is a shame that this is not getting more traction, Grape City (ComponentOne) has this functionality by using their own nuget repository. For developers the installers work, but what about build servers, I really shouldn't need to install the full Dev Express suite on my TeamCity build agents and I'd rather not have the dll's in my source control

Yeah, our Git repo just gets bigger and bigger… some of that could be remedied by git-lfs, but the fact remains nuget is just so much nicer.

It's really ridiculous that we have to use a project like https://github.com/CaioProiete/DevExpress-NuGet. I'm wasting time with git pulling, packaging, verifying, patching (e.g. CaioProiete is still on 15.2.4.0), uploading, etc. But without CaioProiete, doing continuous integration with DX is just not possible. So: Thank you for this great project

Come on DX guys, we are paying quite a lot of money for the (great) DX Components. It can't be that hard to supply nuget packages…

P.S. I think eXpand would also benefit from nuget packages!

Agreed. We too asked for official NuGet packages a in an earlier request to no avail. Other .Net vendors such as Aspose  make their assemblies available in the public NuGet repo and do not seem to have major issues. We mainly are interested in supporting our TeamCity build environment and would be very happy using our private NuGet repo or one hosted by DevExpress that requires authentication.

As a compromise, I would like to propose DevExpress publish nuspec files as part of their standard install process or even the assembly dependency information in an electronically accessible format. This would enable people to build their own NuGet packages for automated build purposes.

We use our own custom packaging process based on Gradle to automate the creation of NuGet packages. The problem is the significant time and effort involved and the inevitable dependency inconsistencies relative to the behavior of the designer in Visual Studio. Extremely annoying since we have to replace the designer added assemblies with equivalent NuGet packages. Since our dependencies don't exactly match the VS designers, we often have manually to remove extra assemblies after switching to the NuGet packages.

DevExpress, please listen to your loyal customers and fix this problem!

+1 for official NuGet Packages

I also like the compromise suggested by David Taylor.
At least give us official nuspec files. So you could keep your custom installer. And like for source code I would have to use your installer to get the nuspec files. But after installing I could use them to create packages and host them on my internal nuget server.
At least I wouldn't have to get the dependencies among your dlls right because you know them way better than I do.

And for the licensing issue:
Starting with 15.1 you already have the licensing menu in Visual Studio (K18106). So after restoring NuGet packages I would have a trial of your products on my machine until I activate it. You could make the activation a standalone application if necessary.
I have no problem with using your installer if I need the source code or CodeRush etc.

It's less about having the current version installed on my developer machine.
It's more about not having older versions installed when I need to debug an old version of my appplication and of course it's about the build server.

Very nice. Thank you. But … probably I have overlooked the packages for WinForms and WPF!?

I uploaded a tool I am using for almost 5 years now. It scans the assemblies and builds packages for it. It does manage depenencies to other Devexpress assemblies, but does not handle framework references.

https://github.com/biohazard999/DXNugetPackageBuilder/Geetings Manuel

We created a utility similar to the one uploaded by Manuel Grundner for our packaging process. Unfortunately, the dependencies declared in the assemblies does not take into account which ones DevExpress treats as optional when adding components to an application. This is problematic when we convert a project from local dependencies to NuGet packages since there is not a one-to-one correspondence.

Maybe we can figure out how indirect/optional dependencies are defined, so we can break the dependency tree?
For xaf the most problematic assembly is DevExpress.Persistent.Base cause it has a reference on DevExpress.XtraReports.Extentions. So almost every Win assembly is pulled in :/

I believe the optionality of an assembly is determined by DevExpress based on expectations of the features typically used for a given component. For example, if I recall correctly, the SparkLine assembly is implicitly required by the GridControl, but is not automatically added by the designer in VS. The dependency information in the GrdiControl assembly, however, dutifully reports the SparkLine assembly dependency.

I recall seeing another ticket a few years back related to this issue in which DevExpress pointed to an XML file they use internally in their installer to manage the dependency information. I looked at it briefly, but did not incorporate it into our packaging process since it was not officially supported and was not being published with each new release.

Infragistics provides nuget packages for some of it's products in the installer.  Why can't devexpress?
http://brianlagunas.com/feature-spotlight-infragistics-wpf-nuget-packages/

To the management team,

Our development teams at Flow-Cal have raised an issue about your current product delivery process.  Our team believes it’s too antiquated for teams that provide continuous deployment.  After reviewing conversations about your plan to provide your assemblies through NuGet, I realized DevExpress maybe missing out on the best delivery method on the market to-date through NuGet.   If you are unaware of the opportunities available to you one tool that our company uses to package our assemblies for customers is Inedo’s PROGET.  At Flow-Cal our product delivery teams can host packages using ProGet’s internal web site, then using our own custom security thorough our website we have the capability to allow customers to download their product subscriptions as a convenience service.  I know that your teams are interested in keeping with current software trends and that you are always willing to collaborate with customers to improve your software offerings.  So the only question is at what point will your product delivery method match your competitors like Infragistics and Telerik who are using tools like NuGet? I am confident DevExpress can do better and as a fan and customer of your products I am confident your development teams can build the right platform for releasing products.

-Solution Architect
Michael Arnwine

Syncfusion also distribute using NuGet:

http://nuget.syncfusion.com/

Sorry, but for me, this is a deal breaker.  So, after 8 years with DX, I'm going to move all new projects to another company.

Shame, shame, shame. Eight years and still not listening to your customers.

Would be really nice to have DevExpress WPF via NuGet like for ASP.Net

Jens,
We started with ASP.NET packages to collect user feedback and understand how to perfect this service. Once we've published it, we'll surely consider adding packages for all DevExpress .NET platforms. In the meantime, we'd like to hear about your WinForms/WPF/whatever scenarios for NuGet. Feel free to email us at Support@devexpress.com.

Serge,

Our team is also using the WPF/Winform packages

We use almost all assemblies but esp Winforms, XPO and XAF.

We use also WPF/Winforms

Winforms and WPF too, please.

+1 for WPF! Thank you.

Having said above that having Nuget packages was a deal breaker, because DevExpress are now working toward providing Nuget packages, I've just renewed my lapsed DXperience subscription.  Happy to be back on board again and am looking forwards to upgrading my apps from DX 2014 to DX 2016 soon.