问题描述
我们拥有了一套实现Web服务操作组件。
We have a set of assemblies which implement web services operations.
要建立客户端代理，我们先在服务器上构建和部署Web服务（组件和ASMX文件）。
To build the client proxies, we first build and deploy the web services (assemblies and ASMX files) on the server.
然后我们使用Wsdl.exe用指向ASMX端点和生成的类的客户端代理。
Then we use wsdl.exe to point to the ASMX endpoints and generate the classes for the client proxies.
我已经看到了，这是可以创建使用Wsdl.exe用或disco.exe WSDL文件（而不是ASMX端点）的代理服务器。
I've seen that it is possible to create the proxies from wsdl files (instead of asmx endpoints) using wsdl.exe or disco.exe.
是否有工具来直接从服务器组件生成WSDL文件，或者代理类，而不需要使用Web服务器？
更新：
首先，我想说我AP preciate你们抽出时间投入到这一点。我还想说，我知道这是多么困难提出建议，而不知道给定方案的所有细节。这就是说，让我更详细的方案，并解决一些要点你们做：
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:
1），这是一个已经发展了几年，现在稍微大的项目。使用ASMX Web服务的决定是WCF的存在之前完成。
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.
2）我已经想过写我们自己的代理生成，并且可能是一种选择，如果我们没有发现这确实是一个工具。
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.
3）我们仍然要绑定到WSDL合同。我试图避免的是在构建过程中有一个Web服务器上的依赖。
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.
4）我们已经自动生成它运行在TFS构建和已经不是问题本身在我们的自动构建的代理。这个问题，因为有人告诉我，是有分裂的构建分为两部分：服务器和放大器;客户。可能有替代品使用一些花哨的MSBuild任务，以避免分裂，但我对这个问题的知识是有限的。
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 & client. There may be alternatives to avoid the split using some fancy MSBUILD task, but my knowledge on that matter is limited.
5）我确实希望构建刹车上TFS生成客户端如果code和服务器端code编译期间不匹配。这应该已经解决了开发人员的机器在办理入住手续前。
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.
6）我们有严格的控制服务器和客户端部分。这组Web服务作为后端到点击一次Windows窗体应用程序。一切都运行在企业内部网。每次合同变化，它与客户机应用程序的新版本进行串联。
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.
7）的WCF不是在短期内对这个组的Web服务的选项。当我加入了这个项目在一年前，我被赋予创建一套新的网络服务与其他内部系统的互操作性的任务。这些Web服务被设计前期可以很容易地升级到WCF一次高层管理人员允许我们使用WCF。我得看看到svcutil.exe的，但如果它做什么我们所需要的，我会换个角度，试图说服高层管理人员采用WCF。
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.
推荐答案
唉，经典的ASMX Web服务和现代化的WCF服务，能够自动生成WSDL为你的能力。如果你去到URL为Web服务端点，你可以简单地通过添加？WSDL的URL的末尾获得WSDL。您通常不希望产生从服务本身...... Web服务的一点是，从代码中分离出你，并让你绑定合同（这是WSDL是......一的code代理合同）。你可以通过几种方法生成客户端代理......无论是与Wsdl.exe用，svcutil.exe的，或通过Visual Studio的添加Web引用或添加服务引用选项。
Well, both classic ASMX web services and modern WCF services have the ability to automatically generate WSDL for you. If you go to the URL for a web service endpoint, you can get the WSDL simply by adding ?WSDL to the end of the URL. You generally do not want to generate proxies from the code of the service itself...the point of web services is to decouple you from implementation, and allow you to bind to contract (which is what WSDL is...a contract.) You can generate client proxies in a few ways...either with wsdl.exe, svcutil.exe, or via visual studio's "Add Web Reference" or "Add Service Reference" options.
如果你确实需要，你可以写你自己的代理生成器。我最近写了一个动态代理生成器，允许在运行时通过温莎城堡IOC容器采用轻质code代（ILEmit）生成WCF服务代理。有各种各样的选择，但关键是你要绑定的WSDL（您的合同），而不是实际的C＃$ C $的服务℃。最理想的办法是写的WSDL，并同时生成客户端代理和服务合同的接口，并从WSDL数据/消息协定。这就是所谓的契约优先服务的发展，也有少数产品，.NET，让契约优先发展。
If you really need to, you could write you're own proxy generator. I recently wrote a dynamic proxy generator that allowed WCF service proxies to be generated at runtime using lightweight code generation (ILEmit) via the Castle Windsor IOC container. There are a wide variety of options, but the key is that you bind to the WSDL (your contract), and not the actual C# code of the service. The most ideal option would be to write the WSDL, and generate both your client proxies and service contract interfaces and data/message contracts from the WSDL. That is called contract-first service development, and there are a few products for .NET that allow contract-first development.
编辑：
您评论说，我并没有真正回答你的问题。也许这是真的，但是，没有真正很好地回答你的问题。您试图自动生成一个客户端代理的建立。这实在不是一个好主意，并可能会导致一些显著构建问题时，你的服务的变化。
You commented that I did not really answer your question. Perhaps that is true, however, there is no real good answer to your question. You are trying to auto-generate a client proxy on build. That is really not a good idea, and will likely lead to some significant build problems when your service changes.
这是示例场景。假设你有IServiceA，它有一个单一的方法，需要一个数据合同作为参数，并返回一个不同的数据合同的结果：
An example scenario. Assume you have IServiceA, which has a single method that takes a data contract in as a parameter, and returns a different data contract as a result:
[ServiceContract]
public interface IServiceA
{
[OperationContract]
SecureOutput SomeSecureOperation(SecureInput input);
}
public class SecureInput
{
public UserCredentials Credentials { get; set; }
public byte[] EncryptedData { get; set; }
}
public class SecureOutput
{
public byte[] EncryptedData { get; set; }
}
可以说，上述服务利用同步加密来加密和解密数据，但那是后来确定是不安全的。所以你更改数据合同：
Lets say that the above service utilizes synchronous encryption to encrypt and decrypt the data, but that is later determined to be insecure. So you change the data contracts:
[ServiceContract]
public interface IServiceA
{
[OperationContract]
SecureOutput SomeSecureOperation(SecureInput input);
[OperationContract]
byte[] GetPublicKey();
}
public class SecureInput
{
public UserCredentials Credentials { get; set; }
public byte[] UserPublicKey { get; set; }
public byte[] EncryptedData { get; set; }
}
public class SecureOutput
{
public byte[] EncryptedData { get; set; }
}
该服务目前采用异步加密，并使用用户的公钥来回报数据进行加密。该服务还具有一个新的操作，让客户获得服务的公共密钥，以便他们可以输入数据进行加密。在合同为您服务发生了变化，并要求您更新客户端code。您的应的版本为您服务......然而，我们所处理的安全性，和老人们必须pcated赞成新的维护安全德$ P $。如果您自动生成客户端代理的建造时间，你有一个严重的问题。您的客户端code是不再与新的代理相兼容，并构建失败。
The service now utilizes asynchronous encryption, and uses the users public key to encrypt return data. The service also has a new operation to allow clients to get the service's public key so they can encrypt input data. The contract of your service has changed, and requires you to update the client-side code. You should version your service...however we are dealing with security, and the old one must be deprecated in favor of the new one to maintain security. If you auto-generate your client proxies at build time, you have a serious problem. Your client code is no longer compatible with the new proxy, and your build fails.
当使用Web服务打交道时，最好是手动处理代理的生成。如果代理需要重新生成（其中，如果你正确版本的服务，应该是罕见一旦合同固化），那么你就不能简单地产生不破的东西。您将需要生成代理，然后更新任何消耗它以符合新接口。我想不出任何情况下，我会想我的生成代理在制作的时候，也没有我想再生我的代理每次构建。我不建议这样的情景给任何人，无论是。我不直接回答你的问题道歉，但我希望我的解释会帮助你建立一个更好的解决方案。
When dealing with web services, it is best to handle proxy generation manually. If the proxy needs to be regenerated (which, if you properly version your services, should be rare once a contract is solidified), then you can't simply generate without breaking something. You will need to generate the proxy, then update anything that consumes it to conform with the new interface. I can't think of any scenario where I would want to generate my proxies at build time, nor would I want to regenerate my proxy every build. I can't recommend such a scenario to anyone, either. I apologize for not directly answering your question, but I hope my explanation will help you build a better solution.
这篇关于是否有任何工具从服务器端组件ASMX代理？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！