Class Reference Collision with Web Service Proxy Class vs. Original Class

Question

basically this is what's going on after researching this more.

If I try to use the type returned by a certain web service method anywhere in my test web project code such as in code-behind I get namespace conflicts because now the web project sees 2 different definitions for it. One as a proxy class in my web service reference namespace and then the original class definition in the referenced project where it's defined and its namespace

So how does one get past this? I've already tried to cast to the namespace where the class is originally defined but no luck, I keep getting errors saying it can't cast to that.

I tried putting a cast on the calls also but no luck.

Check out this video of me clicking to give you more details of code: http://www.elbalazo.net/Post/WebServiceProxyClassIssue.mp4 (be sure to press play..it doesn't automatically start if using quicktime to view this mp4)

Answer 1

I had the same problem when working on two web services that needed to communicate about a year ago.

I believe I solved the problem by defining an interface that both of them implemented and decoupled my code that was dependent on those classes to instead use the interface. This worked out nicely.

I would give you more details but I don't I'm not sure they would be much help.

I would suggest making an IServiceAuthResponse interface and having your classes implement that interface.

Answer 2

It the problem is that you'd quite like to use just the one type:

With .NET 2.0 web-service proxies this is a PITA, and you need to manually port data between the two. Thankfully, this is fixed in WCF, which lets you use types (as long as they match) from other assemblies. You can do this with the /reference param to svcutil.exe, or the IDE walks you through it painlessly in VS2008.

Is switching to WCF at the client a possibility?

If the problem is the namespaces - then either fully qualify them, or use type aliasing:

using OrderDto = Some.Long.Namespace.Order;

then you can use OrderDto to represent Order - but it is only an alias, and only works for the single code file.

Answer 3

Where ever you declare your ServiceAuthResponse objects use the full namesspace regardless of which one you are using. so something like:

Web.Project.Namespace.ServiceAuthResponse response = serviceProxy.getServiceAuthResponse();

When you need to convert one to the other, you won't be able to just do a straight cast, you will need to manually map the data across.

Answer 4

Take a look at SchemaImporterExtensions. Basically Visual Studio 2005/2008 has a way to override how it generates proxies for web services.

Here is a link to the article I used waaay back in the days prior to WCF.
http://www.microsoft.com/belux/msdn/nl/community/columns/jdruyts/wsproxy.mspx

Of course now I use WCF! So I don't have to deal with this anymore, but it will still work with VS 2008.

Answer 5

You can't do what you're trying to do. Stop right now. ASMX web services do not have this feature. Period, that's all there is to it. They never had this feature, they never will have this feature.

This lack has been corrected in WCF.

---

You ask how people can ever use web services (very well, thank you, for about a decade). As a learning exercise, I won't give the full answer right away. Instead, I'll ask you how you would call the web service from a Java client?

Better still, how would a customer you've never heard of call the service using a programming language you've never heard of?

---

The answer is that they would use the proxy classes. See Basics: How Web Services Work for details, but briefly, a client consuming the service will only see the WSDL. The WSDL describes the service in terms of XML Schema, not in terms of .NET types.

---

An earlier comment mentioned your boss thinks that WCF is overkill. Point him to Microsoft says: ASMX Web Services are a “Legacy Technology” and tell him that WCF is not overkill - it's the replacement for ASMX.