Question

This might get a little convoluted so please let me know if you need clarification.

I have a solution which contains the following projects

Project A - WPF application
Project B - ASP.NET application (with exposed webservices)
Project C - Class Library

Both project A and project B reference types that are located in project C, but more importantly project A makes webservice calls to project B using types located in project C.

The problem I am running into is it appears that when making webservice calls I have no way of referencing the types located in project C directly but rather need to use the types as exposed by the webservice.

Now the basic idea of why this is done I understand (obviously typically the consumer of your webservice would only have the WSDL to go from) however in my case this is an internal application (which is part of a single solution) so this is not a concern.

The biggest problem I see with continuing this approach is that any updates to the types in project C will need to be reflected in project B and then “refreshed” in project A. This seems pretty nasty to me. Surely there is a smoother path?

Am I wrong? What is a typical approach to this issue?

Answer 1

You may be a little confused here.

The types in Project C and the types you see when you add a reference to your web service are different.

When you added the Web Service reference. Visual Studio used svcutil.exe, read metadata from your web service (I’m assuming .asmx?) and then created proxy classes for you.

Check the types for the Web Service (they will obviously have the same names). Put your cursor on them and pres F12. It’ll take you to some designer generated code.

So there is no real workaround as such. When you update your types in Project C and then Update your web services in Project B . You will have to Update Service Reference from Project A Which again uses svcutil.exe and regenerates all your proxies.

Also, this is the same way WCF Services work too.