A lot of your stuff is available this way, and it makes upkeep much more convenient. Yet some, like Telerik.Web.Spreadsheet.dll do not appear to be available that way. I am just curious what the reasoning behind that is.
This causes us to have to maintain a binary folder with the DLLs being checked into source control so that our build server can access it. So now instead of just updating a nuget package, we have to install any updates and remember to copy them over to our binary folder.
It is not universe ending or anything, but I just don't understand why you put some tools in your nuget server and some (in the same software package) you do not.
10 Answers, 1 is accepted
Thank you for your valuable feedback!
I fully agree with you that we should provide a NuGet for Telerik.Web.Spreadsheet.dll and I logged an item for it in our backlog.
The internal request is already filed, but unfortunately I cannot provide an ETA when the Telerik.Web.Spreadsheet nuget will become available.
Once its get implemented we will spread the news.
Will you be adding all of the missing DevCraft pieces? Also, would it be possible to list both the DLL and the nuget packages which house a particular API in the documentation? Sometimes it can be difficult to figure out what DLL something is in, much less where to get that DLL. If we know the package, we can install it to get what we need. However, even for those that are currently packaged, it is not always intuitive, and I think some might be available in more than one.
You are welcome :)
As to the documentation, I think these articles might be helpful:
I'll be glad to receive your feedback on them. You can also use the submit feedback form at the bottom of the articles: "Was this article helpful?".
I have seen those articles already, but they do not really address what I am talking about. I am probably not doing a good job of communicating it. The DLL stuff is covered better than I remember in the actual API documentation, but the nuget stuff is not. In particular, there is nothing about how to handle the DLLs in the "AdditionalLibraries" folder. If I download and install Telerik.UI.For.AspNet.Ajax.Net45, I am not going to get any of those DLLs, and they are all referenced at some point in the sample projects for Telerik UI for ASP.NET AJAX. So I go there to get some idea on how to do something, and then find out I need those other libraries. I then go looking for where to get their nuget packages. After some time I find some of them, but not others. I end up spending hours looking for them. If this were in the API documentation the way the DLLs are, it would save so much time. Finally, some seem to be available in the Sitefinity nuget repository, but not the one for Telerik.
Again, thanks for your help on this.
I am going to update the Telerik NuGet Feed in Visual Studio article with information how to collect all nuget packages and from where!
Thank you for this additional feedback for the account wide login for the DevCraft and Sitefinity.
The Telerik DevCraft (https://nuget.telerik.com/nuget) and Sitefinity (http://nuget.sitefinity.com/nuget) nuget servers have different domains and it may be a technical challenge to operate with shared credentials. Nevertheless, we will have in mind your request and if there are more feature requests like yours, we will consider it.
Thank you once again for sharing your good ideas with us!