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.