Question

Ok… serious problem.

I did the update, thinking that I could continue to use the CTP2 version of Microsoft.Data.Services.Client the library to connect till they updated the Silverlight bits. No go. Ok, I can live with that.

I rolled back the service to the CTP2 libraries ( Microsoft.Data.Services + Microsoft.Data.Services.Client ) recompiled and then updated the service reference in silverlight.

At this point, the service AND the SL3 client are all using the CTP2 bits. Should be fine right? Wrong. Very, very wrong.

System.Data.Services.Client.DataServiceCollection’ does not contain a constructor that takes ‘2’ arguments

This is a serious show stopper, and it was not mentioned that this update would break CTP2 functionality. The warning about the SL dll was not, honestly, enough 🙂

Any ideas on how to resolve this? Should I try and uninstall the update or can I specify an older library in in a config file someplace?

Help! 🙂

Ken

Answer 1

Firstly the problem is that one of your project is picking up the wrong assembly it may be the service but most probably it is the client application.

The available constructors in the CTP 2 v1.5 for the DataServiceCollection are:

private DataServiceCollection();
internal DataServiceCollection(IEnumerable<T> items);
protected DataServiceCollection(DataServiceContext context, string entitySetName, IEnumerable<T> items, Func<EntityChangedParams, bool> entityChangedCallback, Func<EntityCollectionChangedParams, bool> collectionChangedCallback);
internal DataServiceCollection(DataServiceContext context, string entitySetName, Func<EntityChangedParams, bool> entityChangedCallback, Func<EntityCollectionChangedParams, bool> collectionChangedCallback, IEnumerable<T> items);

The Constructors available in the RTM release (the update you installed) KB976126 are:

public DataServiceCollection();
public DataServiceCollection(IEnumerable<T> items);
public DataServiceCollection(DataServiceContext context);
public DataServiceCollection(IEnumerable<T> items, TrackingMode trackingMode);
public DataServiceCollection(DataServiceContext context, string entitySetName, Func<EntityChangedParams, bool> entityChangedCallback, Func<EntityCollectionChangedParams, bool> collectionChangedCallback);
public DataServiceCollection(IEnumerable<T> items, TrackingMode trackingMode, string entitySetName, Func<EntityChangedParams, bool> entityChangedCallback, Func<EntityCollectionChangedParams, bool> collectionChangedCallback);
public DataServiceCollection(DataServiceContext context, IEnumerable<T> items, TrackingMode trackingMode, string entitySetName, Func<EntityChangedParams, bool> entityChangedCallback, Func<EntityCollectionChangedParams, bool> collectionChangedCallback);
internal DataServiceCollection(object atomMaterializer, DataServiceContext context, IEnumerable<T> items, TrackingMode trackingMode, string entitySetName, Func<EntityChangedParams, bool> entityChangedCallback, Func<EntityCollectionChangedParams, bool> collectionChangedCallback);

I suggest if you want to use the CTP dlls, that you check your references on your client application and any other application that makes use of the System.Data.Services.Client.dll and change to Microsoft.Data.Services.Client.dll (located in program files in the the ADO.NET Data Services V1.5 CTP2 folder).

I have installed the latest version also and am am currently running both versions on my PC which it is working.

Another important thing is to check the global assembly cache since both versions will be installed there (with the CTP 2 ddls having an version number of 99.0.0.0).

Something I have done is for the CTP dlls I added the references from the ctp folder instead of the global assembly cache.

Regards

Daniel Portella

Update: Soulhuntre it must be the EntityClassGenerator that the web service reference is using, the service reference must be using the GAC system.data.services.client dll to generate the classes instead of the old CTP ones.
There is two things you can do really one is to do what I said above and the other is to remove the updated (uninstall the KB) that should revert the changes done. You could even try removing the old service reference and creating it again while making sure it uses the CTP dlls to generate the classes.

It works on my solution because I have written my own implementation of the DataServiceClientGenerator, to do magical things that the one shipped by MS doesnt do that must be why i can run both installations with out problems.

End of Update.