Ambiguous reference in WCF and client application

Question

I've managed to reproduce one of the errors in a test project with a similar structure to my production code. It consists of three simple projects:

Common (class library):

namespace Common
{
    public enum PrimaryColor
    {
        Red,
        Green,
        Blue
    };
}

Library (WCF service library), which has a reference to Common:

using Common;

namespace Library
{
    [ServiceContract]
    public interface ILibrary
    {
        [OperationContract]
        PrimaryColor GetColor();
    }

    public class Library : ILibrary
    {
        public PrimaryColor GetColor()
        {
            return PrimaryColor.Red;
        }
    }
}

ClientApp (console application), which has a reference to Common, and a service reference to Library called "LibraryServiceReference":

using Common;
using ClientApp.LibraryServiceReference;

namespace ClientApp
{
    class Program
    {
        static void Main(string[] args)
        {
            LibraryClient client = new LibraryClient("WSHttpBinding_ILibrary");
            PrimaryColor color = client.GetColor();
        }
    }
}

The app.config files in ClientApp and Library are auto-generated and I have not modified them, and I have not changed the default configuration for the LibraryServiceReference in ClientApp.

When I compile this solution, I get the following errors in the ClientApp project:

Error 1

'PrimaryColor' is an ambiguous reference between 'Common.PrimaryColor' and 'ClientApp.LibraryServiceReference.PrimaryColor'

Error 2

Cannot implicitly convert type 'ClientApp.LibraryServiceReference.PrimaryColor' to 'Common.PrimaryColor'. An explicit conversion exists (are you missing a cast?)

please help me to fix this.

score 4 · Answer 1 · answered Jun 18 '12 at 13:37

4

Make sure that 'Reuse types in all referenced assemblies' is selected in the Advanced options of Add service reference or Configure Service Reference.

enter image description here

answered Jun 18 '12 at 13:37

VJAI

32,167
23
102
164

score 3 · Answer 2 · answered Jun 23 '16 at 19:04

3

it's because you're building x64 not "AnyCpu". I am running across this right now, and am trying to figure out if it's a bug, or if it's expected behavior.

answered Jun 23 '16 at 19:04

eric frazer

1,492
1
12
19

Your answer is a comment, and not an answer. – Matsmath Jun 23 '16 at 19:33
1

I disagree. In my project, I switched it from x64 to AnyCpu and the ambiguous reference went away. I'm no expert on this, but I think when the project it set to x64, there is a bug when generating the proxy code. I think since the type has been pre-jitted, the proxy generation has no option but to reverse-compile it, and generates the proxy-side class duplicate. When it's AnyCpu, it can unwind the type itself. I work at MS, and know one of the guys who wrote WCF, and even he said it was a real stumper why AnyCpu works but x64 doesn't. – eric frazer Jun 23 '16 at 21:01
@ericfrazer Did you ever research this further: bug or expected behavior? Switching my DLL to AnyCPU from x64 fixed the problem. I would rewrite this as an answer and i will mark it as such as it resolves the issue. – markf78 Oct 24 '17 at 01:47
1

@ericfrazer Be sure to add the obvious "Assuming you've already enabled the "Reuse types in referenced assemblies..." to your answer to be 100% correct. – markf78 Oct 24 '17 at 01:51
@ericfrazer did you get any further with this? "Reuse types in referenced assemblies" is selected an no luck for me! – metoyou May 11 '19 at 12:05

score 1 · Answer 3 · answered Jun 18 '12 at 14:25

1

Decorate your enum like this:

namespace Common
{
    [DataContract]
    public enum PrimaryColor
    {
        [EnumMember]
        Red,
        [EnumMember]
        Green,
        [EnumMember]
        Blue
    };
}

Update Your service reference (with checking reuse types just like Mark stated).
Rebuild your client code.

answered Jun 18 '12 at 14:25

Grzegorz W

3,487
1
21
21

helped me!! I was missing the [EnumMember] attributes and the type which was using this enum was duplicated!! Thanks again!! – Darxis Dec 08 '12 at 19:12

score 1 · Answer 4 · answered Aug 09 '16 at 14:47

I have had this issue arise in innocuous, unpredictable manners so many times! I thought I'd share how I "fixed" it this last time.

I am using Visual Studio 2013 - but have had the issue down rev.

The ambiguous reference seems to come on by itself. I did nothing of note to cause it. In the latest instance I was debugging some code behind and suddenly I had 7, then 22 then 49 errors - all of the same nature.

I deleted the service reference altogether and re-added it. Simply modifying the re-use type did nothing. My solution has a WCF service, Class Library, UI and a Control Library. I also removed the using - in some code behind, of the class library.

This is an exceptionally troublesome issue which thankfully only occurs about every few weeks. Why this worked? Beyond my pay grade. I feel your pain! Hope this helps. In this case, the error came on, again, when I opened some code behind on a xaml page.

I've seen this when adding a service reference that references a library to a client application without first adding same reference to library in client application and checking the reuse types. — JMIII, Oct 14 '20 at 19:26

Bronumski · Answer 5 · 2012-06-19T09:10:40.983

It sounds like you control both the client and the server code. Why do you want to create a service reference, is there a specific reason or is it just deemed easier?

In projects where you control both sides of the client server application you are better of creating a "contract assembly" (which is probably your common assembly). This contains the interfaces and objects that are involved with the contract and should be referenced by both your client and your server. In order to communicate with the service the client creates a proxy class using the ChannelFactory, there is no need to have a dedicated WCF client.

Example:

ChannelFactory<ISampleService> factory = new ChannelFactory<ISampleService>("Binding_from_config");

ISampleService sampleService = factory.CreateChannel();

sampleService.SomeCall();

factory.Close();

The factory pattern also makes it an ideal candidate for injecting your proxy in via IoC.

The benefits of referencing a common assembly over creating a service reference are:

No ambiguous reference as there will be no need for auto generated classes.
You will not have to update your service reference every time you change the contract.

score 0 · Answer 6 · answered Jun 20 '19 at 16:43

For what it's worth, I was running in to this same error after moving my data contracts to a separate library. Updated the service references multiple times and tried all combinations of the settings for assembly reuse, to no avail.

What eventually fixed it for me was to 1) restart Visual Studio and 2) update the service reference. The auto-generated code in Reference.cs in the service definition looked very different and did not duplicate my data contract class. It used the proper reference from my library. So something must be getting cached in the IDE.

Hopefully someone else finds this useful.

score 0 · Answer 7 · answered Sep 11 '19 at 15:03

0

I was able to fix this by right-clicking on the Service Reference and then changing from "Reuse types in all referenced assemblies" to "Reuse types in specified referenced assemblies" and then checking the specific common assembly.

answered Sep 11 '19 at 15:03

Johannes Eggers

1

score 0 · Answer 8 · answered Mar 13 '20 at 11:29

Just remove the reference to Common project from your ClientApp project and the error should go away. When you're creating a proxy for your service, all dependent code from the service must be injected into the proxy. If you want your types to be same as those on the service side, just enable the 'Reuse types' option while generating the proxy code (otherwise they will be put under a different namespace).

score -1 · Answer 9 · answered Jun 18 '12 at 13:36

-1

The problem here is that PrimaryColor exists in both Common and ClientApp.LibraryServiceReference and you are referencing both namespaces in your class.

To overcome this issue, either explicitly reference the instance that you require, i.e.

Common.PrimaryColor color = ....

or set up an alias:

using Service = ClientLibraryServiceReference; ...

Service.PrimaryColor color = ......

answered Jun 18 '12 at 13:36

DaveRead

3,371
1
21
24

@DavidRead This will leave me with an overhead of writing a conversion method which will convert between Client.PrimaryColor and Service.PrimaryColor back and forth. What if I have 100's of different classes in the service that I need to refer in the Client code?? what do you say? – CuriousBenjamin Nov 05 '12 at 14:10
I am left with only option to manually edit the refernce.cs file nothing much. Could not figure out the underlying issue in the code. More helping brains needed.. :) – CuriousBenjamin Nov 05 '12 at 14:12

Youp Bernoulli · Answer 10 · 2012-06-20T12:03:22.410

When making the service reference aren't there some options that say something like: "inlcude common types in generated service contract" ?

I have the idea that in your service reference the classes are "copied" and that's why you get this error. Inspect the generated service files, remove then and add them again with "Add Service Reference" and see what options you have there.

EDIT

Although I'm almost sure that the Type PrimaryColor is defined twice. One time in the common project and one time in your service reference, you can also try this in your clientApp (to more explicitely specify the PrimaryColor Type):

Common.PrimaryColor color = client.GetColor();

Sorry It did not help.. :( @youpTube – CuriousBenjamin Jun 18 '12 at 17:14 — CuriousBenjamin, Jun 18 '12 at 17:14

Ambiguous reference in WCF and client application

10 Answers10

Linked

Related