更改 WCF 中的命名空间和 schemaLocation 属性

我用 C# 开发了一个 WCF 服务。我们的客户已经有一个用 Java 编写的客户端软件。他们说当他们尝试添加我们的 wcf 服务引用时，他们收到错误。他们认为问题在于命名空间。
我对 WCF 中的命名空间或任何其他标记详细信息了解不多。
他们说 wcf 服务的 wsdl 输出必须如下所示：

<xsd:import id="base" namespace="http://helios.theircompanyName.com/im schemaLocation="http://wwwdev1.theirCompanyName.com:8000/HeliosIM/im?xsd=1"/>

但我们的服务提供：

<xsd:import schemaLocation="http://myComputerName/MyWcfProjectFolder/MyWcfService.svc?xsd=xsd0" namespace="http://tempuri.org/"/>

可以看出，我的服务没有类似的属性id="base" and namespace, schemaLocation属性不同。
我怎样才能改变WCF来生成他们想要的wsdl xml？

如果您想从 tempuri.org 更改服务的命名空间（这是 WCF 默认值），您需要在 4 个位置进行更改：

1. 服务合同
2. 数据合约
3. 服务实施
4. 端点配置元素中的 BindingNamespace

例如：

// Service Contract
[ServiceContract(Namespace="http://myNamespace")]
public interface IMyService
{}

// Data Contract
[DataContract(Namespace="http://myNamespace")]
public class MyType
{}

// Service implementation
[ServiceBehavior(Namespace="http://myNamespace")]
public class Service : IMyService
{}

<!-- In config -->
<endpoint address="http://whatever" 
          bindingNamespace="http://myNamespace"
          binding="basicHttpBinding" 
          contract="Something.IMyService" />

然而，我真的不明白为什么他们告诉你这是必要的。作为服务的提供者，提供什么命名空间取决于您而不是他们。无论该值设置为多少，它们在使用 wsdl 时都可能会遇到相同的问题。

schemaLocation 也是如此，同样，这个位置指向哪里并不取决于他们。当您在 xml 架构中进行导入时，架构位置实际上是完全可选的，因此，如果它们依赖于其中的某些值，那么它们就不符合 xsd。

我猜想他们在使用您的 WSDL 时遇到了困难，并且不太明白出了什么问题，因此选择责怪您的服务。通过 basicHttpBinding 公开的服务元数据是整个 WCF 堆栈中互操作性最强的，并且应该 100% 可从 java 使用。

他们如何努力建立客户？您的服务是否在他们可以看到的地方运行？