title: Are there any tools to build ASMX proxies from server side assemblies?
body: <p>We have a set of assemblies which implement web services operations.</p>
  
  <p>To build the client proxies, we first build and deploy the web services (assemblies and ASMX files) on the server.</p>
  
  <p>Then we use wsdl.exe to point to the ASMX endpoints and generate the classes for the client proxies.</p>
  
  <p>I've seen that it is possible to create the proxies from wsdl files (instead of asmx endpoints) using wsdl.exe or disco.exe.</p>
  
  <hr>
  
  <p><strong>Is there a tool to generate wsdl files or proxy classes directly from the server assemblies without the need to use a web server?</strong></p>
  
  <hr>
  
  <p>UPDATE:</p>
  
  <p>First I would like to say I appreciate you guys taking the time to put into this. I also would like to say that I know how hard it is to give advice without knowing all the details of a given scenario. That said, let me detail more the scenario and address some points you guys made: </p>
  
  <p>1) This is a somewhat large project that has been in development for over a couple of years now. The decision to use ASMX web services was made before the existence of WCF.</p>
  
  <p>2) I already thought about writing our own proxy generator and that may be an option if we don’t find a tool that does it. </p>
  
  <p>3) We still want to bind to the WSDL contract. What I’m trying to avoid is having a dependency on a web server during the build process. </p>
  
  <p>4) We already auto-generate the proxies in our automated build which runs in TFS Build and that has not been an issue per se. The issue, as I was told, is having to split the build in two parts: server &amp; client. There may be alternatives to avoid the split using some fancy MSBUILD task, but my knowledge on that matter is limited.</p>
  
  <p>5) I do expect the build to brake on TFS Build if the client side code and server side code don’t match during compilation. That should have been addressed on the developer’s machine before check-in.</p>
  
  <p>6) We have strict control over the server and the client parts. This set of web services serve as a back-end to a Click Once Windows Forms application. Everything runs on an intranet. Every time the contract changes, it is done in tandem with a new version of the client application.</p>
  
  <p>7) WCF is not an option in the short term for this set of web services. When I joined the project over a year ago I was given the task of creating a new set of web services for interoperability with other internal systems. Those web services were designed upfront to be easily upgradable to WCF once upper management allowed us to use WCF. I’ll have to take a look into svcutil.exe, but if it does what we need, I’ll have another point in trying to convince upper management to adopt WCF. </p>