views:

353

answers:

3

For brevity purposes, this post relates to ambiguous references in a Silverlight Page.XAML.CS file, whose project contains a service reference to a WCF service and a MyClass.cs file added as a 'link'. The Solution contains the Silverlight Project and a Web Project that contains a WCF service and a MyClass.cs file (along with the aspx files etc).

For some reason I am getting ambiguous reference errors once I add the service reference to Page.xaml.cs. Prior to adding the using statement for the service ref, I had one for MyClass.cs (which remember had been added to the SL project as a link) to the page, and it was running fine. Once the SVC ref is added, the compiler complains about ambiguity in my call to any class / property in 'MyClass.cs, such that a reference to MyClass.Class becomes ambiguous to 'ServiceReference.MyClass.Class...Seems very strange to me.

Assumptions & Clarifications

I ensured that no namespaces, class names, methods or variables had similar names
WCF service must reside in web application to have access to other non Silverlight assemblies etc
Other .cs files in the Silverlight project reference MyClass.cs, otherwise I would have simply removed the link to MyClass.cs, and allowed referenced MyClass.cs through the service ref.

My assumption here is that this has something to do with adding a file as a link? Any KungFu Masters out there able to offer some insight as to why this is occurring, alternatives to adding as a linked file, other ideas?

+1  A: 

Is MyClass a class used by the service for which you added a Service Reference? If true, then there are two versions of each class in MyClass.cs: one from MyClass.cs, and one from the service reference.

You should pick one or the other - either use the service or don't use the service.

John Saunders
+1  A: 

If you've added "MyClass.cs" as a link in both your Silverlight and Web projects then it will most likely cause a name collision, fortunately they should be in seperate namespaces. The linked class will be in the original namespace and the one generated by the Service Reference will be in the generated namespace.

You can use the "Reuse Types in Referenced Assemblies" option when generating the Service Reference so that the generated service proxy uses your linked class rather than generating a new one. There are however a couple of tricks to get this to work correctly, I outlined these in a post a few months ago Resuing types in Silverlight Service References.

I hope this helps.

Nigel Sampson
A: 

Nigel Sampsons Answer led me in the right direction, thanks a million!

The Solution Create a new project for the class file, and add a reference to that project in your Silverlight Project. Then when you ad your service reference and select "Reuse Types in Referenced Assemblies", it will not generate it's own implementation of the class, eliminating the ambiguous reference.

Unlike a typical client / server service scenario the class file must be compiled seperately for Siverlight and ASP.NET.

PortageMonkey
It's because they're two different platforms, with different Frameworks.
John Saunders