Web Services Stumper: Ambiguous Types

Discussion in 'ASP .Net Web Services' started by Mini-Tools Timm, Jan 16, 2008.

  1. 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.
    Mini-Tools Timm, Jan 16, 2008
    #1
    1. Advertising

  2. 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. :)

    --
    Gregory A. Beamer
    MVP, MCP: +I, SE, SD, DBA

    *************************************************
    | Think outside the box!
    |
    *************************************************
    "Mini-Tools Timm" <info at mini-tools dot com> wrote in message
    news:...
    >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\), Jan 21, 2008
    #2
    1. Advertising

  3. 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
    Mini-Tools Timm, Jan 21, 2008
    #3
  4. 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.

    --
    Gregory A. Beamer
    MVP, MCP: +I, SE, SD, DBA

    *************************************************
    | Think outside the box!
    |
    *************************************************
    "Mini-Tools Timm" <info at mini-tools dot com> wrote in message
    news:...
    > 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\), Jan 21, 2008
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Nick
    Replies:
    1
    Views:
    6,117
    Alvin Bruney - ASP.NET MVP
    Sep 12, 2005
  2. Anup
    Replies:
    1
    Views:
    2,774
    Mark Rae
    May 9, 2006
  3. J Krugman

    malloc stumper

    J Krugman, Dec 4, 2004, in forum: C Programming
    Replies:
    10
    Views:
    547
    Dave Thompson
    Dec 13, 2004
  4. Markus Dehmann
    Replies:
    3
    Views:
    319
    Jeff F
    Sep 21, 2007
  5. John
    Replies:
    4
    Views:
    427
Loading...

Share This Page