RadDataServiceDataSource Problem Visual 2012

[Santiago]

Hello Telerik,

Im having trouble with the RadDomainDataServiceDataSource, it is asking me for the System.Data.Service.Client library but my Silverlight project don't use that library anymore.. It is using the Microsoft.Data.Service.Client.SL. I have the 2012.01.320 version of telerik silverlight Extensions.

When I remove the library and add the System.Data.Service.Client I got a problem with the Service Reference because it use the enumeration System.Data.Services.Common.DataServiceProtocolVersion

Please Help me with It


Thank you

Santiago Muñoz

[Rossen Hristov]

Hello,

Does this compile-time error occur in the server project, i.e. in the DataService<T> class in the server web project?

Kind regards,
Rossen Hristov
the Telerik team

[Santiago]

No, this error is in the Client Project, Silverlight project.

I have attached 2 images to better understanding the problem. When I add a service reference on the Silverlight Project, the code generated on Reference.cs file contains a declaration using the DataServiceProtocolVersion Enum. Yo can see this on picture1 of the attached files. This enumeration is available on the Microsoft.Data.Service.Client.SL assembly. This assembly use Visual 2012. So I fix it adding that assembly to the references, But when I add that assembly and delete the System.Data.Service.Client assembly I get the error with RadDataServiceDataSource, It says that needs the assembly System.Data.Service.Client 5.0.5.0, check the picture2. And of course I cant add the two assemblies because it raise an error saying that the "System.Data.Service.Client.DataServiceContext exists in the two assemblies"

[Rossen Hristov]

Hi,

Our control is built against the standard assemblies, i.e. the one that start with System.* and are part of the Framework.

Currently it can not target these new assemblies that Microsoft are releasing out-of-band. Unfortunately, we cannot build our control against both sets of assemblies since there will be thousands of ambiguous references since they contain the same classes.

All the best,
Rossen Hristov
the Telerik team

[Santiago]

So RadControls for Silverlight is not fully supported on Visual 2012?

[Rossen Hristov]

Hi,

Visual Studio 2012 is an IDE.

WCF Data Services 5.0 are custom DLL's offered by Microsoft by NuGet.

WCF Data Services 5.0's DLL's are not part of the .NET Framework yet. That is why they begin with Microsoft.* and not with System.*.

Once they become an official part of the .NET Framework, we will support them out-of-the-box.

As I already explained, we have no way of building against the official version of WCF Data Services which is part of the .NET Framework and the new version (starting with Microsoft.*) which is not part of the .NET Framework at the same time.

So I cannot agree that "RadControls for Silverlight is not fully supported on Visual 2012"?

What I can offer you is to see whether I can build our source code against this new version and if it is possible, I can send you a custom build targeting these 5.0 assemblies.

All the best,
Rossen Hristov
the Telerik team

[Santiago]

Yes you are right that is a nugget package I was confused about that library but Visual 2012 is using it for Silverlight applications, maybe there is a way to configure visual to don't use it. 

Im agree with you now. Visual Studio should use the System.Data.Service.Client assembly for default and not the other one.

 Thank you I will really appreciate if you can send me a custom build targeting that assembly.

[Raja]

Experiencing the same issue and would appreciate any workarounds.

[Rossen Hristov]

Hello,

You can simply make sure that you add a reference to System.Data.Service.Client.dll instead of Microsoft.Data.Services.Client.dll. This is the assembly which our assembly was built upon.

Plese, read this article. Here is a quote from it:

System.* indicates stuff that is logically part of the framework. It is 100% supported, solid-long term design that will not need to churn, safe to bet on, stable, likely will get great tooling support. Designed to be very interoperable and could work anywhere .NET is. This may ship as part of the redist or maybe an out of band (such as ASP.NET MVC, ASP.NET AJAX, etc).

Microsoft.* is the bleeding edge stuff or value-add. It is typically very cool stuff that adds on to the framework and enhances it, but maybe a work in progress... over time you might expect some of those concepts to go into the framework. As an example, the great work patterns and practices does often falls into this bucket.

I hope this makes things more clear now.

We have discussed the matter and I am afraid that at the time being we cannot produce such a build. Sorry for misleading you.

Kind regards,
Rossen Hristov
the Telerik team

[Santiago]

Is not so simply because when I use the  System.Data.Service.Client.dll assembly, I get the error on the Service Reference. I tried also removing the Microsoft* assembly and then Adding the service reference but It seems that the code generator for the service reference always use the Microsoft* Assembly.

Anyway, I was working around on it and the only way to Fix It is to use as you said the System.Data.Service.Client.dll assembly instead of Microsoft.Data.Services.Client.SL.dll. and modify the generated Code on the "Reference.cs" of each Service Reference on Silverlight Client.

At the constructor of the Reference.cs file that you can access when you enable "Show All Files" in solution Explorer, You will find this line:

public ModelName(global::System.Uri serviceRoot) :
base(serviceRoot, global::System.Data.Services.Common.DataServiceProtocolVersion.V2)

Change this to

public ModelName(global::System.Uri serviceRoot) : base(serviceRoot)

and That's It. Fixed.

Please Update Us when you Release an assembly that works with the other library 'cause we don't know when we will get another conflicts between the two libraries...

Thank You

Santiago Muñoz 

[Andrew]

Rossen,

I know about the difference between Microsoft.* and System.*, however it looks like Microsoft is pushing towards using NuGet.
Here is a quote from WCF Data Services home page, at the bottom: http://msdn.microsoft.com/en-us/data/ee720179:

.NET Framework

"Previously releases of WCF Data Services have been included in the .NET Framework. The releases of WCF Data Services in .NET support OData v1 and v2 and have been superseded by the NuGet packages."

Note 'superseded'.
The NuGet packages include the latest WCF DataServices v5.
It's a stable RTM release, which have support for OData v3.
It's an import release bringing support for different OData features, performance and stabilization.

Since RadDataServiceDataSource was built against the .NET Framework's System.Data.*, this means I am forced to use a very old version of WCF DataService, I am not able to use the latest version.

Any idea how to fix this situation?
Would it be possible to try and build RadDataServiceDataSource from the source?
I need a fast solution because I already started working on a new project for a customer.

Thanks,
Andrew

[Rossen Hristov]

Hi,

Unfortunately, we cannot create a different version of the control for every new NuGet package that is released by MS. We will have to support one version targeting the System.* assemblies, and then one version for each version of the assemblies coming in as a NuGet package which would be quite a mess.

We will think about how can we be always up-to-date with those NuGet releases, while maintaining all old versions, since many of our customers are still using the System.* assemblies. You have to agree that .NET Framework/Silverlight version releases and NuGet package releases are quite different for third-party control vendors, i.e. releasing a new version of a control involves much more than simply building a bunch of files against some specific assemblies.

Did you try the solution offered by Santiago Munoz in the previous post? Can you simply change the references of your project to use the Microsoft versions. If the new API is the same they should be able to build.

Also, building from the source code against a particular version of the Microsoft assemblies *should be* possible, however we could not find any indications about a purchased license from your account.

Regards,
Rossen Hristov
the Telerik team

[Santiago]

Hi,

Well When you add the Service Reference it doesn't build normally, Visual Studio throws an error but you can simply modify the "Reference.cs" file of every service reference as I mentioned in my other post and the project is able to build. It is a problem because you have to modify this file every time that you Update the Reference or add a new Reference but is a fast solution and it works perfect!!! You can see my older Post (Posted on Nov 9, 2012) where I explain all the procedure to fix it..

Grettings

[Raja]

Glad, Telerik has resolved the issue with the latest Q1 2013 release of OpenAccess. Starting to use VS2012 with my WCF Data Services. - Thanks