Bozhidar said: Since only official releases are uploaded to nuget, in order to test the internal build you have to use it from a local package source.
I would strongly suggest that you need to either revise your policy regarding nuget internal builds, or at the very least revise your online documentation.
According to the online documentation for your nuget packages (http://docs.telerik.com/aspnet-mvc/getting-started/nuget-install#nuget-packages), the very first line of the the description states the following:
NuGet is a popular .NET package manager. Official releases, service packs and internal builds of UI for ASP.NET MVC are available for registered users.
This certainly seems to indicate that registered users should expect internal builds to be available on the private feed as pre-release packages.
Additionally, your documentation makes no mention of any other methods for obtaining internal builds of the ASP.NET Core wrappers, or where to obtain the .nupkg archive file. The Getting Started documentation mentions an option for manual installation of the clients-side components, but not the wrappers. The ASP.NET Core wrappers documentation appears to be steering users away from the older approaches (via VSIX or manual install), and focusing solely on installation via package managers. This newer approach makes perfect sense, unless you aren't given the ability obtain all the necessary builds, and are forced to switch to an undocumented manual process.
To add additional complication/confusion, internal builds ARE currently available for Kendo UI via the bower package manager. In your online documentation for the Bower Packages page (http://docs.telerik.com/kendo-ui/intro/installation/bower-install), the phrasing used is almost identical to what is used on the nuget packages page, yet the behavior is completely different.
As a result, your product documentation is out of sync with the your support responses/messaging, and the deployment practices for the MVC and Core wrappers is not consistent with the practices of the underlying Kendo UI Core/Professional product.
My apologies if I have overlooked something, and please correct me where wrong, but this is how I see the current situation, as a customer:
- misleading, incomplete, or inaccurate documentation
- conflicting behavior/practices between teams responsible for components/products, even though both components are needed
- lack of advanced warning/alert/notification. I was personally unaware of these issues, prior to upgrading my application to ASP.NET 2.0. There has been no mention of this in product newsletters, support alert emails, blog entries, website notifications, etc. As far as I can tell, there isn't even a pinned forum post for this topic.
- In order to resolve or work around this issue, the developer would need to:
- be aware that Telerik's nuget documentation is incorrect (the documentation discrepancy could lead one to assume that no internal builds exist)
- be aware that an internal build has been released to correct these specific compatibility issues
- be aware of how to obtain internal builds (not documentated, but probably only an issue for newer licensees, in light of the recent trend towards delivery via package managers)
- be aware of how to obtain the nuget package archive from within the internal build (not documented)
- be aware of how to set up a local nuget package repository to host this internal build (not documented)
Considering that this is coming on the heels of (at minimum, using official release date) a 10 day wait for the 2.0 compatible version, or as an unexpected "gotcha" after migrating an existing application to ASP.NET Core 2.0, you are undoubtedly going to be dealing with a number of confused and frustrated customers.
Based on the thread history, this issue was identified during pre-release for ASP.NET Core 2.0, and has been on the radar for several months. I can understand that your policy is to not target pre-release versions, but it sounds like you didn't even have a separate internal branch created beforehand to work on compatibility/migration; I may have misread, but it sounds like that process didn't begin until the day after ASP.NET Core 2.0 launched.
Also, there appears to have been ample time to notifiy subscribers of potential compatibility issues with the current release version of the Core wrappers, but this does not appear to have happened (again, my apologies if something was sent that I overlooked). This sort of proactive action can save a significant number of wasted hours and dollars, on the customer's side.
By comparison, I have been contacted by Progress 4 times in the past 30 days about renewing my Kendo subscription, which isn't set to expire for several months. This juxtaposition of proactive and reactive behavior paints a poor picture of Progress' priorities, with regard to product support and customer care.
In my opinion, the creation of prominently placed Knowledge Base article, blog post, or even a consolidated and pinned forum post (with thorough documentation of the problem, the symptoms, and every step needed for implementing/deploying the internal build as a workaround) could go a long way towards preventing confusion and frustration for others, as they make the switch to Core 2.0.