Web Services Stumper: Ambiguous Types

[Mini-Tools Timm]

I have a web service question that has stumped me and the experts I've
consulted thus far. Here is my challenge:

When a client connects to a C# web service, how can it bind to a specific
DLL in the web service "bin" folder?

The gritty details… I have a shared assembly (shared.dll) that is referenced
both by a C# WinForms client (client.exe) and a C# Web Service (service.dll).

When I upload the service to the Web, naturally both service.dll and
shared.dll are uploaded to the "bin" folder. Defined in service.dll is a
class called "DataService" that provides the web service methods I need. To
access this web service, client.exe uses code in shared.dll to construct and
use a DataService object. Therefore, the following proxy class is generated
in Reference.cs for shared.dll:

public partial class DataService :
System.Web.Services.Protocols.SoapHttpClientProtocol

The problem occurs when I attempt to execute a method on the DataService
object from client.exe. It throws the following exception:

The type 'MyNamespace.DataService' is ambiguous:
it could come from assembly '\bin\service.dll'
or from assembly '\bin\shared.dll'.
Please specify the assembly explicitly in the type name.

I understand the ambiguity. There is the proxy definition for DataService
in shared.dll (that inherits from SoapHttpClientProtocol). Then there's the
full class definition of DataService in service.dll. The web service doesn't
know which to choose and throws an exception.

My question is, how can I resolve this ambiguity? How do I explicitly tell
the web service to use the DataService definition in service.dll? The
DataService.asmx file only has a Class attribute, but nowhere to specify a
specific assembly.

 

[Cowboy \(Gregory A. Beamer\)]

I read a few times and I would have to see the code to get a better idea of
what you are doing.

If my assumption is correct, use a higher level library to set up the
syncrhronized class (ie, send as a parent in the hierarchy) and cast to the
client implementation on the winforms application. This avoids the problem
as the inherited class is not the same on both sides, or at least not
passed.

Another common pattern is to translate from a web service type to the local
type. You have to do this in almost every case where you are consuming
services from vendors and clients, so why not use this pattern on your own
software. Sure, it adds a bit of overhead, but it solves any "ambiguity"
issues and is a pattern you can use with every web service implementation,
internal or external. You just alter the proxy to translate types for you.
The first suggestion follows this basic pattern, but simplifies the
translation as you merely cast to the local type.

If my assumption is incorrect, then none of this applies.

 

[Mini-Tools Timm]

Gregory,

Thank you for your response. I indeed had to re-architect the solution as
you described and got it working. My customer had a requirement for a single
DLL, but I was able to convince him that a separate DLL to contain the client
connector code was appropriate.

Regards,
Timm

 

[Cowboy \(Gregory A. Beamer\)]

Cool.

I ended up with the same issue on a project I worked on a few years ago. The
"architect" I took over from had a clever way around the problem, but it
just obfuscated other, more dangerous, issues.