8

I have a web service and a client. The classes used in parameters and return types are in a common DLL shared by both. However, whenever I update the web reference, visual studio generates copies of the classes with the same names and public properties and methods. Then the solution won't compile because the client code tries to use the versions in the common DLL. I can solve the problem by deleting the "duplicate" classes every time I update the web reference, and adding a using statement to point at the common dll's namespace. Is there a way to fix this permanently?

UPDATE: See my comments below. This is a "feature" of asmx web services. There is no way around it other than one of the following: 1) Use a more modern type of web service. 2) Don't use a common DLL 3) Manually fix every time you update the web reference, as in the original question above.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
stannius
  • 1,260
  • 3
  • 16
  • 33
  • 1
    According to this similar question http://stackoverflow.com/questions/134064/reuse-existing-types-is-ignored-when-adding-a-service-reference, "Reuse Types" is not supported for "old school" (asmx) web references. – stannius Sep 12 '12 at 22:52
  • http://stackoverflow.com/questions/3389679/how-does-visual-studio-2008-and-svcutil-decide-which-types-to-re-use-from-refere – stannius Sep 12 '12 at 22:59
  • You should add your comment as an answer. I would then upvote. – John Saunders Nov 05 '12 at 23:59

4 Answers4

2

This is a "feature" of asmx web services. There is no way around it other than one of the following:

  • Use a more modern type of web service.
  • Don't use a common DLL
  • Manually fix every time you update the web reference, as in the original question above.

Sources: Other stackoverflow questions:

Community
  • 1
  • 1
stannius
  • 1,260
  • 3
  • 16
  • 33
1

There`s no way to do that.

However, I think we have a design problem here. When we create a web service, we expect that our clients don't need to reference any dll from us. Only the types exposed by the web service should be enough for their use (web services are all about interoperability, imagine your client app written in Java, you can't reference the .NET dll).

That's why these types are created when you reference a web service. In my opinion, you should only rely on the classes generated by the web service in your client app. Remove the reference to the shared dll from the client project.

This doesn't direct answer your question, but provides an alternative for your issue.

Fabio
  • 3,020
  • 4
  • 39
  • 62
  • 1
    Downvoter, please provide an explanation for your vote. Thanks. – Fabio Nov 06 '12 at 12:12
  • My guess is because it doesn't answer the question. "Should I hammer this in with an old shoe or glass bottle" notwithstanding. – stannius Nov 14 '12 at 23:34
  • Yes, @stannius, maybe that's the reason. I changed my answer a little so people with "hammering shoes" can't complain abou it. BTW, I hope my answer was helpful for you, in some manner. – Fabio Nov 16 '12 at 16:49
  • Fabio -- yeah you have to be sure to address the main question and then promote best practices later. Even if the answer should be avoided. Thanks! I've inherited a legacy app and I've been real busy just trying to get things to work. This helped me realized that client app shouldn't have the .dlls that the service does. – IEnjoyEatingVegetables Jan 10 '22 at 20:22
1

I had the same problem, but I had neglected to add the reference the correct assembly with the request/response types in my client. Once I added that reference, and ensured that the "Reuse types" checkbox was on in the Add Service Reference dialog, it worked properly.

Ben Whitney
  • 29
  • 2
1

In the domain class, set AnonymousType=false to prevent generating class with prefix unexpected when adding the web reference
[System.Xml.Serialization.XmlTypeAttribute(AnonymousType = false)] but this only ensure that the class, auto-gen in Reference.cs has the same structure as the domain class.

A way to walk aroud this is to serialize/deserialize to the domain object.

Martin
  • 31
  • 3