This is a migrated thread and some comments may be shown as answers.

.NET Core 2.0 Support

47 Answers 500 Views

General Discussions

This is a migrated thread and some comments may be shown as answers.

47 Answers, 1 is accepted

answered on 16 Aug 2017, 06:22 AM

As said in previous posts there not much to change to get 2017.2.0621 to get working:-

In class DataSourceRequestModelBinder function public virtual Task BindModelAsync(ModelBindingContext bindingContext) change the return to Task.CompletedTask

in the same class function TryGetValue replace action((T)value.ConvertTo(typeof(T)));

with :-

object valueToConvert = null;
if (value.Values.Count == 1)
{
valueToConvert = value.Values[0];
}
else if (value.Values.Count > 1)
{
valueToConvert = value.Values.ToArray();
}
var convert = TypeDescriptor.GetConverter(typeof(T));
action((T)convert.ConvertTo(valueToConvert, typeof(T)));

worked for me and am using it in production - I may have missed something but didn't find it too hard.

answered on 29 Aug 2017, 11:38 PM

[quote]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. [/quote]

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.

answered on 05 Sep 2017, 06:31 PM

[quote]Jamie Hassall said: I have the pre release in a zip format, from account downloads, but there is no way to install it via local nuget?[/quote]

Hi Jamie! Bozhidar posted about information about how easily set up a local nuget repository. I believe he posted it the same day the first internal build was published, but I'm quoting again it below this message. Steps are very simple, and should get you up and running in no time. The link below is to a Stack Overflow posting, but there are are also plenty of other resources available, just Google "local nuget repository" if you need additional help.

Warmest Regards,
Ozz

[quote]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. Here's a detailed explanation on how you can use a nuget package from a file directly:
https://stackoverflow.com/questions/10240029/how-to-install-a-nuget-package-nupkg-file-locally[/quote]

answered on 08 Sep 2017, 08:54 AM

Hi all,

I'll try to address the concerns from a few posts ago, on Aug 30.

First and foremost, the documentation of our NuGet feed is indeed misleading, citing that the internal builds are available, when in fact they are not. At least not in the feed. Please excuse us for this miscommunication. We will update the articles, so that they don't present false information. We will also try and document the process of using internal builds with Asp.NET Core better, so that there is no further confusion.

Internal builds of UI for ASP.NET Core can be downloaded from the "Your Account" > "Products and Subscriptions" section at telerik.com

As for the timing of the release, there are several factors at play. First, we didn't receive any advance notice of the release of the 2.0 version, or a version containing all of the changes. We did have a branch where we kept a version up-to-date with the preview versions. When the release dropped, it caught us by surprise, and there were several new issues we had to address, apart from the ones discussed in this thread. The dynamic process meant that we couldn't say with certainty that we have an official ready to market version that supports 2.0. Also, when we release an internal build, it also has to be thoroughly tested for all known scenarios and functionalities, after the fixes are made. I agree that for clients 10 days might seem a long time, and we certainly try to be as quick as possible, but at the same time we don't want to release half-baked internal builds, that don't work properly and cause more frustration.

Regards,
Bozhidar
Progress Telerik

Try our brand new, jQuery-free Angular 2 components built from ground-up which deliver the business app essential building blocks - a grid component, data visualization (charts) and form elements.