CODEWITHSUNDEEP
c#wsdl.exesvcutil.exe
RAVI KANDARPA
RAVI KANDARPA

Reputation: 71

wsdl.exe/svcutil.exe - is there a way not to generate the classes for types in the xsds during a Web service or client generation

We have a centrally managed object model for types in the schema in C#. We want every one across the enterprise use that object model instead of using the one generated each time from wsdl/svcutil during a webservice client or service implementation.

is there a parameter(any other way) to wsdl/svcutil not to generate classes for the schema types during theie execution?

Upvotes: 7

Views: 5917

Answers (3)

marc_s
marc_s

Reputation: 754468

I don't know of any specific setting or command line switch to enforce this - what you can do, but that's mostly a matter of training and enforcing by checking, is to share the class library (the assembly, in a DLL) with the developers, and make sure that everyone references that common class library and leaves the default settings in the "Add Service Reference" dialog (on the "Advanced" page) alone:

alt text

Here, you define that WCF will reuse any types it can find in any of the referenced assemblies - so if your developers add a regular reference to the common data contracts library, then WCF will use those types instead of re-creating them over and over again.

But again - that's only a "management by example and checking" kind of approach - I don't know of any technical way to enforce this.

Upvotes: 3

Daniel Auger
Daniel Auger

Reputation: 12611

If you remove the mex endpoint from the service config file, the client app will not be able to discover and generate the proxy objects.

A way to handle this situation if I understand your question correctly is to do the following:

  1. Create a common set of DLLs that has the service, and datacontracts / shared object model.
  2. Create a service using the contracts in the common dll instead of the contracts visual studio creates when you create a new service.
  3. Remove the MEX endpoint from the server config file (this will essentially break proxy generation).
  4. Have your client use the the common dll and manually create the channels on the client side (via channel factory etc...).

In this approach you do not use wsdl.exe/svcutil.exe at all since you are essentially bypassing the wsdl. You do not add service references either since you are manually managing the connections.

EDIT: Following this approach, the client can still try to generate proxy objects via wsdl.exe/svcutil.exe, but they won't get the correct information from the wsdl. They'll essentially generate a non-functioning / incomplete proxy.

Upvotes: 0

mythz
mythz

Reputation: 143319

I believe what you are looking for is: svcutil.exe /r your-dtos.dll

/reference: - Reference types in the specified assembly. When generating clients, use this option to specify assemblies that might contain types representing the metadata being imported. (Short: /r)

In my opinion the tight coupling of the WCF proxy, endpoint channel, service operations and dto payloads into the same generated client proxy is a major design flaw.

This is what spurred me to solve in my open web services framework where I decouple the end point and payload which allows:

  • The same web service client (i.e. Soap11, Soap12, XML, JSON) to be able to call any web service.
  • It lets me also use the same DataContract dto instance in any of the web service clients
  • This has many benefits including being able to expose the same web service on a number of different end points without any extra configuration. Thus providing optimized web service endpoints for each consumer of my service. E.g.
    • XML for interoperability and strongly-type clients,
    • JSON for Ajax clients,
    • WSDL's for environments that prefer generated code (i.e. Flex Builder, VS.NET 'Add Service Reference' etc)

At my company we have developed hundreds of web services called by a number of different clients i.e. Ajax, Flash/ActionScript, C++, Silverlight, ASP.NET and being able to call the same web service through different endpoints has saved us countless hours.

Upvotes: 3

Related Questions