我可以在不更改服务的情况下更改 WCF ServiceContract 接口的命名空间吗?
有没有办法更改 WCF ServiceContract 接口的 .NET 命名空间,同时仍使 WCF 服务向后兼容使用旧(除了命名空间之外相同)ServiceContract 的客户端?例如,假设我有(在 vb.net 中):
Namespace MyCompany.MyPoorlyNamedProject
<ServiceContract(Name:="ThingService")> _
<CLSCompliant(True)> _
Public Interface IThingService
...
End Interface
EndNamespace
我想将其更改为
Namespace MyCompany.MyProject
<ServiceContract(Name:="ThingService")> _
<CLSCompliant(True)> _
Public Interface IThingService
...
End Interface
End Namespace
根本不更改服务。
我尝试这样做,但是从 wsdl 引用的 xsd 显示了新的命名空间名称,这似乎是不兼容的。
有什么想法吗?
Is there a way to change the .NET namespace of a WCF ServiceContract Interface yet still make the WCF service backwards-compatible with clients that are using the old (identical except for namespace) ServiceContract? For example, suppose I have (in vb.net):
Namespace MyCompany.MyPoorlyNamedProject
<ServiceContract(Name:="ThingService")> _
<CLSCompliant(True)> _
Public Interface IThingService
...
End Interface
EndNamespace
And I want to change that to
Namespace MyCompany.MyProject
<ServiceContract(Name:="ThingService")> _
<CLSCompliant(True)> _
Public Interface IThingService
...
End Interface
End Namespace
Without changing the service at all.
I tried just doing so, but my xsds referred to from the wsdl show the new namespace name, which seems to be an incompatibility.
Any ideas?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
只要服务合同的名称和 (XML) 命名空间不发生变化 - 当然! WCF 服务实际上并不关心它们的实现方式的 .NET 内部结构。
只要客户端使用标准
添加服务引用
方法(询问服务的元数据以创建单独的客户端代理)附加到您的服务,这种方法就有效 - 在这种情况下,客户端代理不了解任何服务端 .NET 命名空间...您可以更改服务端的命名空间并重新部署您的服务文件 - 客户端将继续工作。您唯一需要进行调整的地方是服务端的配置(如果您在 IIS 中托管,则在
web.config
中,则在托管商的app.config
中) code> 否则):
标记的name=
属性具有服务类的完全限定 .NET 类型名称(包括 .NET 命名空间)< ;endpoint>
标记的contract=
属性具有服务协定的完全限定 .NET 类型名称(包括 .NET 命名空间)显然,如果您与服务契约共享公共程序集,则这不起作用 - 在这种情况下,客户端将绑定到公共程序集中这些合同文件的 .NET 命名空间,如果这些更改,客户端将不再工作。
As long as the name and (XML) namespace of your service contract don't change - sure! WCF services really don't care about the .NET internals of how they're implemented.
This works as long as the client side attaches to your service using the standard
Add Service Reference
method (interrogating the service's metadata to create a separate client-side proxy) - in that case, the client-side proxy has no knowledge of any service-side .NET namespaces... you can change those on the service side and redeploy your service files - the client will continue to work.The only place you'll need to make an adjustment is in the config of your service side (in
web.config
if you're hosting in IIS, in your hoster'sapp.config
otherwise):the
<service>
tag'sname=
attribute has the service class' fully qualified .NET type name (including .NET namespace)the
<endpoint>
tag'scontract=
attribute has the service contract's fully qualified .NET type name (including .NET namespace)This doesn't work, obviously, if you share a common assembly with the service contract - in that case, the client side will be tied to the .NET namespace of those contract files in a common assembly and if those change, the client won't work anymore..