WCF服务引用命名空间由原来的不同 [英] WCF service reference namespace differs from original

问题描述

我有关于我的服务引用使用的命名空间的问题。我有一些WCF服务，与命名空间 MyCompany.Services.MyProduct 说（的实际的命名空间是长的）。

作为产品的一部分，我也提供样品C＃.NET网站。这个Web应用程序使用的命名空间 MyCompany.MyProduct 。

I'm having a problem regarding namespaces used by my service references. I have a number of WCF services, say with the namespace MyCompany.Services.MyProduct (the actual namespaces are longer).
As part of the product, I'm also providing a sample C# .NET website. This web application uses the namespace MyCompany.MyProduct.

在最初的发展，该服务中添加作为项目引用到网站并直接使用。我用返回一个对象实例，实现 MyCompany.Services.MyProduct.IMyService A工厂模式。到目前为止，一切都很好。

During initial development, the service was added as a project reference to the website and uses directly. I used a factory pattern that returns an object instance that implements MyCompany.Services.MyProduct.IMyService. So far, so good.

现在我想改变这种使用一个实际的服务引用。添加引用和命名空间中的文本框中键入 MyCompany.Services.MyProduct 之后，它在命名空间中生成类的 MyCompany.MyProduct.MyCompany.Services.MyProduct 。的 BAD！的，我不希望有使用几个地方指令只是因为我使用的是代理类改。于是，我试着用前面加上全球命名空间：，但是这是不能接受的。

Now I want to change this to use an actual service reference. After adding the reference and typing MyCompany.Services.MyProduct in the namespace textbox, it generates classes in the namespace MyCompany.MyProduct.MyCompany.Services.MyProduct. BAD! I don't want to have to change using directives in several places just because I'm using a proxy class. So I tried prepending the namespace with global::, but that is not accepted.

请注意，我就没'吨甚至删除了原始程序集引用着呢，重用类型已启用，但没有重用做，显然。 不过，我不希望在我的样本网站围绕保持集引用为它工作，反正

Note that I hadn't even deleted the original assembly references yet, and "reuse types" is enabled, but no reusing was done, apparently. However, I don't want to keep the assembly references around in my sample website for it to work anyway.

唯一的解决办法我已经想出到目前为止是我的web应用程序设置默认名称空间 MyCompany的（因为它不能为空），并添加服务引用为 Services.MyProduct 。假设一个客户要使用我的示例网站作为一个起点，他们改变了默认的命名空间为 OtherCompany.Whatever ，这显然会破坏我的解决方法。

The only solution I've come up with so far is setting the default namespace for my web application to MyCompany (because it cannot be empty), and adding the service reference as Services.MyProduct. Suppose that a customer wants to use my sample website as a starting point, and they change the default namespace to OtherCompany.Whatever, this will obviously break my workaround.

是否有一个很好的解决这个问题。

Is there a good solution to this problem?

总结：我想要生成在原有的命名空间服务引用代理，而不引用的程序集

To summarize: I want to generate a service reference proxy in the original namespace, without referencing the assembly.

请注意：我看到的这个问题，但没有提供解决方案，是对我的使用情况下可以接受的。

Note: I have seen this question, but there was no solution provided that is acceptable for my use case.

---

编辑：正如约翰·桑德斯建议，我已经提交了一些反馈给微软这个：

反馈产品@ Microsoft连接

As John Saunders suggested, I've submitted some feedback to Microsoft about this:
Feedback item @ Microsoft Connect

推荐答案

的我添加了一个的写了这个解决方案的到我的博客。相同的信息真的，但也许有点不太支离破碎的

I've added a write-up of this solution to my blog. The same information really, but perhaps a little less fragmented

我发现使用替代 svcutil.exe的来完成我想要的。它（IMO），使更新服务引用比重新运行程序更容易。

I've found an alternative to using svcutil.exe to accomplish what I want. It (imo) makes updating the service reference easier than rerunning the utility.

您应该明确您的ServiceContract和DataContracts（指定一个命名空间URI的见下文的注释的）。

You should explicitly specify a namespace uri on your ServiceContract and DataContracts (see further below for comment).

[ServiceContract(Namespace = "http://company.com/MyCompany.Services.MyProduct")]
public interface IService
{
    [OperationContract]
    CompositeType GetData();
}

[DataContract(Namespace = "http://company.com/MyCompany.Services.MyProduct")]
public class CompositeType
{
    // Whatever
}

该命名空间可以是任何东西，但在技术上它需要一个有效的URI，所以我选择了这个方案。您可能需要手动生成的东西以后工作，所以做到这一点。

The namespace could be anything, but technically it needs to be a valid uri, so I chose this scheme. You might have to build manually for things to work later, so do that.

一旦做到这一点，启用显示所有文件的选项解决方案资源管理器。展开您以前添加的服务引用。 。双击 Reference.svcmap 文件

Once this is done, enable the Show All Files option in the Solution Explorer. Expand the service reference you added previously. Double click the Reference.svcmap file.

将有一个< NamespaceMappings / > 元素，你需要编辑。继续我的例子：

There will be a <NamespaceMappings /> element, which you will need to edit. Continuing my example:

<NamespaceMappings>
    <NamespaceMapping
        TargetNamespace="http://company.com/MyCompany.Services.MyProduct"
        ClrNamespace="MyCompany.Services.MyProduct" />
</NamespaceMappings>

保存文件，用鼠标右键单击该服务的参考和选择更新服务参考

Save the file, right click the service reference and select Update Service Reference.

根据您的需要（其实我需要两个），您可以添加尽可能多的映射。其效果是一样的 SvcUtil工具/命名空间：的方法，但无需使用命令行UTIL本身，使得更容易更新

You can add as many mappings as you need (I actually needed two). The effect is the same as the svcutil /namespace: approach, but without having to use the command line util itself, making for easier updating.

这样做的缺点的做法是，你需要使用明确的命名空间映射。使用 SvcUtil工具，你必须映射一切没有明确这样映射（溶液约翰·桑德斯指的）的选项：

The downside to this approach is that you need to use explicit namespace mappings. Using svcutil, you have the option to map everything not explicitly mapped like this (the solution John Saunders was referring to):

svcutil /namespace:*,MyCompany.Services.MyProduct ...

您可能会想使用：

<NamespaceMappings>
    <NamespaceMapping
        TargetNamespace="*"
        ClrNamespace="MyCompany.Services.MyProduct" />
</NamespaceMappings>

但是，这将不可以的工作，原因是Visual Studio已经隐式添加这种映射指着我们试图摆脱生成的命名空间名称。 。上述的配置将导致Visual Studio抱怨重复键

but this will not work, because Visual Studio already implicitly adds this mapping, pointing to the generated namespace name we're trying to get rid of. The above configuration will cause Visual Studio to complain about a duplicate key.

广告明确的命名空间：

如果没有explit命名空间在代码中指定的，它的看起来的是.NET将产生以下形式的URI的 http://schemas.datacontract.org/2004/07/ MyCompany.Services.MyProduct 。你可以映射一样好，在我的例子明确的命名空间，但我不知道是否有这种行为的任何保证。因此，有一个明确的命名空间将可能会更好。

Ad explicit namespaces:
When no explit namespace is specified in your code, it seems that .NET will generate a uri of the form http://schemas.datacontract.org/2004/07/MyCompany.Services.MyProduct. You could map that just as well as the explicit namespaces in my example, but I don't know if there is any guarantee for this behavior. Therefore, going with an explicit namespace might be better.

的注：需要映射两个TargetNamespaces相同的ClrNamespace似乎打破代码生成的

这篇关于WCF服务引用命名空间由原来的不同的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！