NuGet or Not for Telerik?

by Chris Eargle | Comments 39

At Telerik, we strive to make the installation process for trials or licensed copies of our software easier. Earlier this year, we released the Telerik Control Panel, which helps keep our licensed customers up to date on their purchased products and trials installed on their machines. We also provided packages that can be installed by the Extension Manager (Extensions and Updates in Visual Studio 2012) requiring authentication when a project is created.

As NuGet gains popularity, we have researched whether we can support it and what the user experience will be like if we do. We associate each user with a Telerik account for both trial and licensed products, a standard business model among tool vendors. However, the default NuGet experience does not require authentication. This creates a frictionless experience, but it will not work for us for many of our products. We do provide packages for our free frameworks, such as JustMock Lite.

The default NuGet experience is not the only route available; NuGet does support authentication. We have built a prototype for a Telerik NuGet package source, and we can make NuGet work from both the NuGet Package Manager Console and the Manage NuGet Packages dialog inside Visual Studio. So what is the catch? You must provide connection and authentication details.

Our question is this: given this need for extra information, do developers want the option to use NuGet with Telerik products?

Telerik Experience from the NuGet Package Manager Console

Imagine you have a WPF project open in Visual Studio and would like to add support for Telerik WPF controls. Here is how things would work from the NuGet Package Manager Console. You begin by opening the PM console and typing the appropriate command to retrieve the package.

We need to know who you are to determine whether to install trial or licensed products on your machine. This requires you to provide a Telerik.com-based NuGet URL to the –Source option of the Install-Package command (the localhost URL is for our prototype).

Next, you must provide your Telerik.com credentials to authenticate.

Finally, NuGet installs the correct package.

With the package installed, you can now develop almost as you normally would. Unfortunately, we have found no way to do Toolbox integration as part of a NuGet install. In other words, our designers continue to work as expected, but our controls will not be in Visual Studio Toolbox for the drag-n-drop design-time experience. There is a manual work-around, but the extra steps eliminate the benefits of using NuGet. This may not be a problem for some, as many frameworks either do not require or even support toolbox controls. For example, Kendo users are not affected and XAML developers can still use markup. Those most affected are WinForms developers, since the designer is more often used.

Telerik Experience from the Manage NuGet Packages Dialog

Many developers find the Manage NuGet Packages dialog within Visual Studio intuitive as the experience is similar to the Extension Manager. With your WPF project loaded, start by adding the Telerik.com-based NuGet URL to Package Sources in the Package Manager page of Visual Studio Options. Unlike the NuGet Package Manager Console, you only need to provide the URL once.

Next, open the Package Manager UI.

Then you would login. The Package Manager allows you to browse available Telerik packages.

You can now choose the Telerik WPF package from the list and install it.

Finally, you can use the Telerik WPF controls.

What Do You Think?

The benefit of using NuGet is that you can do the whole thing from within Visual Studio, via the console or GUI, and you can check for updates along with your other NuGet components.

The downside is that you need to know the appropriate URL to Telerik.com, although it would probably be something simple like http://nuget.telerik.com or http://telerik.com/nuget. You also need to have an account on Telerik.com.

How do you feel about this? Is it a good NuGet experience? Is it better than using the trial installer or Control Panel in some scenarios? If this is viewed as an essential experience, we can give this feature priority. Understand that if we decide to go this route, it may delay another feature you would prefer us to do. There are vocal proponents of NuGet support, but so far, we have not encountered a broad demand.

Let us know what you think, but please keep this conversation to whether Telerik should support NuGet with its existing business model and not whether Telerik should shift to a business model that does not require users to authenticate. Telerik is actively pursuing different business models for new products, but we are unlikely to do a major shift on our existing products. Such a conversation is unlikely to be helpful.

Thank you for your feedback. We will continue to pursue the best user experience possible in the ever-changing world of software development.

About the author

Chris Eargle

Chris Eargle

is a Telerik Technical Evangelist and Microsoft C# MVP with over a decade of experience designing and developing enterprise applications, and he runs the local .NET User Group: the Columbia Enterprise Developers Guild. He is a frequent guest of conferences and community events promoting best practices and new technologies. Chris is a native Carolinian; his family settled the Dutch Form region of South Carolina in 1752. He currently resides in Columbia with his wife, Binyue, his dog, Laika, and his three cats: Meeko, Tigger, and Sookie. Amazingly, they all get along... except for Meeko, who is by no means meek.

Posted in: extensions

39 Comments

Kevin Kalitowski
I am definitely pro-NuGet in some manner or another.
I have been putting Telerik dlls into a local NuGet repository for a long time and find NuGet to be very helpful.  It takes a lot of effort on my part to keep these packages up to date when a new Telerik release occurs.
The one issue I see involves NuGet Package Restore.  We do not check the assemblies into TFS and instead let Visual Studio download them on an as-needed basis. Without a way to store the password (encrypted) in the solution, our TeamCity build server would have no way to authenticate with the NuGet and download the assemblies.
One alternate solution to consider is distributing NuGet packages for clients to install into their local NuGet repository using a tool like NuGet Package Explorer.  That tool generates *.nupkg files that could packaged with the Telerik installer.  Or perhaps some command-line script that could install the files into a local NuGet server without intermediary *.nupkg files.
Maarten Balliauw
At MyGet we would love to offer you guys something which handles the following:

- Every user gets his own feed (http://nuget.relerik.com/F/someuser)

- Telerik can add packages that are licensed to a user's feed

- Telerik can add packages that are free to every user's feed



We're negotiating with some others to do something similar so feel free to contact us.        
G.

Chris – we all appreciate your efforts to reach out to the Dev community and figure out alternative ways to deliver content to us.

Here are my 2 cents on the subject:

NuGet is a great tool for delivering a framework or two quickly (and resolving dependencies in the process.) But the way I see it, your products go beyond that description. I very much like the integrated Toolbox experience as well as all project-type templates. With the addition of your Control Panel, Telerik has made a significant step toward one-stop content delivery tool – a fact that most of us like. In respect to this, I am not sure what value a NuGet package delivery would add (save couple additional mouse clicks per product release.)

In conclusion, to me, the value provided via the Control Panel and the seamless VS integration far outweighs the effort I need to put in starting Control Panel and clicking on “Update all”. My vote (for whatever that is worth) goes to sticking with the Control Panel.

Henrique Duarte
I think that NuGet is better because of it's integration with Visual Studio. It's simple and everybody knows how to use it.
So my vote is for NuGet!
Tony McKinney
The thing that I like about about NuGet, besides it being integrated into VS, is that it adds the dependencies to the project and makes team development easier so +1 for NuGet.
Harry Pfleger
+1 for NuGet:

1. much better user experience, what is faster

2. there can be different version in different projects

3. easier when using Source Control (dlls go into SC)
Richard Orchard
+1 for NuGet as an option.



For me, it would make managing dependencies on the build machine easier to deal with.
Rick Dorris
One less place to worry about updates. +1 for NuGet.
EShy
+1 for Nuget.
I'm developing on multiple PCs, more than once I had an issue for library dll locations (first PC had the latest dlls in the updates folder, second one had it in the main install since I just did a clean install)
Using NuGet with package restore solves that.  
Nabil Shuhaiber
NuGet is a must for us as all our dependencies are hosted in a local repository. We are having to create custom packages for our telerik dll's which is cumbersome and slows down our ability to upgrade to newer versions. Definitely a +1 for NuGet here and looking forward to it. The experience mentioned above is good enough.
Robert McLaws
+1000 for NuGet. Please consider using MyGet as an option, they are a fantastic service. Also, please consider including weekly builds in the process as well as "Prerelease" builds. And for Kendo, please distinguish between the JS libraries and the MVC assembly as separate packages. I want to get MVC updates automatically, but I put my JS and LESS files in different folders than your packages would place them.
Hesham Desouky
+4 NuGet 
1- Much more easier to install
2- Apply updates much more easier (in case of using local copies of Telerik Dlls).
3- Source control much more easier for nuget
4- Most of time I am interested on updating the binaries, I can see the help online which is much more easier and faster than the local copy)
Ben Martin
+1 for NuGet.
Would like some way of saving the account details.
GMR
+1 for control panel, if Nuget cant manage VS toolbox then it will never be able to provide a full solution. It is likely that in the future other modifications to VS may be needed, with control panel that can be easily included. For me control panel has been a great tool with a lot of potential, I would rather see the dev money go to enhancing control panel rather than NuGet which will never be able to accomplish all facets of VS setup etc.
Sörnt
+1 for NuGet.
* much easier updating to newer versions.
* better workflow with source control and build server systems. Currently I copy the telerik dll somewhere next to the project. So my build server can pick them up after checking the project out from the source control system. I don't install Telerik components at the build server.
Jens
+1000 control Panel
Chris Eargle
It appears that NuGet is popular as an option, despite the need for extra information. We will take this into consideration along with the support shown to the Control Panel.
It is difficult to ask about NuGet support priority without exposing other features we are planning. So, if you think something else is more important or if you think NuGet is the most important. Please let us know.
Laurent Kempé
NuGet became the standard for most of the .NET Developers, it is kind of standard now. I think it is definitely a plus to have it support.
Having a new feed and credential is really ok.
Concerning the toolbox, you might get in touch with the NuGet people to come to a solution for a next release.
Eirik
+1 for NuGet
We are running a NuGet server to distribute internal frameworks and shared code and also use credentials. It works like a dream!
mike
Forget about your own control panel. You as a vendor are really not that important to me as a developer. I only care about your tools, not about your brand. So please let get at my tools, and don't bother me with your 'shinyness'.
In other words: yes to NuGet, no to custom control panels.
Chris
Yes! we definitely want this and the auth layer is more than acceptable. We do the same thing internally for our private enterprise feed.
Buzz
We are in the process of setting up a local nuget feed.  As mentioned by Kevin (1st poster) and Nabil, if telerik had nuget packages all ready for us that would make life easier.
Adam
+1 for nuget, its catching on like wildfire and it can become a single point of delivery that all developers will be familiar with.
My suggestion was going to be a simple thing like an api key in the query string instead of credentials.  This would allow nuget package restore to work as well as allowing the delivery of custom feeds on a per account basis.
With that said I would look into myget options if they are willing to accommodate.  That sounds like the best and easiest approach.
Chris Eargle
Hi Dustin, the NuGet package source in the article is a prototype. We have not published it at this time.
Wayne
Your telerik control panel is great - keep working on it.  However, it is an issue to make sure each developer has right version of telerik installed on their machine and then build servers, etc.
So nuget is really a must outside one user.  I would say integrate with myget and then all the problems are resolved?  You could publish each users licensed products (for active subscriptions) to their feed and then you are done.  That would be how I would ADD telerik to my project - I would also use the control panel to keep toolboxes and other things up to date.
Pauli
+100 Control panel and Upgrade wizard. Before Control panel I many times skipped new versions but not anymore because now upgrading is so easy. :-)
Brendon
+1 NuGet. Just getting started in MVC and everything appears to work much much much smoother than anything else I have ever worked with in Visual Studio. Can we have it yesterday or at least a beta feed to plug into? I just wasted 2 hours getting the KendoUI GPL version installed via NuGet because your package isn't polished. Hopefully the licensed version is?!
Stuart Hemming
I like the idea of using NuGet for this.
Olaf
+1 for NuGet
I agree with Kevin Kalitowski, Nabil Shuhaiber and Buzz. We do not put external libraries under source control. We are running a custom nuget repository which holds all the internal and external libraries. Developers retrieve these dependencies with the help of the package restore feature of nuget.
Assembling the Telerik DLLs into nuget packages each time a new version is released generates a significant effort on our side. For us it would be sufficient when there is an additional download option for a nuget package in the download area.
doug
NuGet is a must!
Our company will actively move away from any product that does not support NuGet as it is a requirement for our new CI system.
We'll temporarily continue to package Telerik controls, but not for long.
Chris W.
Definitely +several, especially for "lighter" products with no Visual Studio integration to speak of (Kendo, etc.)
Mike
Telerik controls are the last external dependencies that I commonly use which are not available via NuGet. Maybe I'm spoiled now, but I cringe when I have to figure out which dlls are used by which controls, copy them to a project folder, add to source control, etc...I don't have to do this for *anything else*!

Time to get on the bus, guys! :) 
Patrick Earl
Just as another poster alluded to, it would be best to have virtual private NuGet repositories keyed to some per-user identifier.  For example:

http://nuget.telerik.com/<random per-user identifier>

Users would get this special per-user URL in their control panel and when accessed, only packages that the user is licensed to have would show up.

We also internally use NuGet for all our Telerik packages.  We have them split up like:
Kendo -> The main javascript, themes, etc.
Kendo.Mvc -> Just the .NET libraries.  Referred to by our framework projects.
Kendo.Mvc.Content -> The extra stuff that gets installed into the website.  (This depends on the other two.)

Unfortunately we have to make our own builds anyways due to a few minor changes that don't seem to want to make their way back into the upstream source.

Robert R.
Please find some kind of NuGet solution for packaging Telerik libraries. I think providing secure NuGet package feeds for subscribers through MyGet.com as mentioned above along with symbol and source server support through its integration with SymbolSource.org would be great. Either that, or provide us with the release and debug (symbols+source) packages (or official guidance for creating them) to host them ourselves in our own private feeds.
Peter L.
+1 for NuGet w/ symbols as detailed above by Robert R.
Jeff S.
+1 for NuGet - If possible include support for updating Visual Studio Toolbox and Telerik Control Panel.
Thierry L.
+1 for Telerik NuGet.
Marc-David Johne
+1 for NuGet packages
+1 for Symbol server

Comments

  1.    
      
      
       
  2. (optional, emails won't be shown on public pages)
  3. (optional)
Read more articles by Chris Eargle - or - read latest articles in Developer Tools