12

在 Visual Studio 2010 中将我的第一个“服务引用”添加到客户端项目时，我遇到了这个奇怪的命名空间问题。

如果我的项目的默认命名空间使用两个或更多部分，例如MyCompany.MyApp，当添加服务引用时，将创建一个 Reference.cs 文件，其中包含MyCompany.MyApp.ServiceReferenceName具有大量具有完全限定名称的自动生成代码的命名空间，System.SerializableAttribute例如System.Runtime.Serialization.DataContractAttribute.

Reference.cs 文件将充满编译错误，因为编译器开始将 System 命名空间视为命名空间的子成员MyCompany.MyApp。您会遇到很多错误，例如：

The type or namespace name 'Runtime' does not exist in the namespace 'MyCompany.MyApp.System'...

如果我将 Reference.cs 文件顶部的命名空间修改为一些简单的东西，例如MyCompanyMyApp.ServiceRefernceName，编译器会表现并将 System 命名空间引用识别为 .net 的 System 命名空间的 decleration。

我现在正在使用不同的解决方法，因为我真的想保留我的多部分命名空间。我目前的替代方法是global::在 System 命名空间引用前面附加以强制编译器做正确的事情。事实上，如果“添加服务引用”向导使用 T4 模板，我可能会修改这些模板以在源代码中嵌入我的解决方法。

问题

我真的很想了解这里发生了什么以及为什么多部分命名空间会导致此问题。大概命名空间比我想象的要多。其次，真的很想制定一个比每次添加服务引用或使用一些 T4 模板时都执行全局查找/替换更好的解决方案。

4

8 回答 8

27

我发现这里的答案有些不清楚，所以我想我会添加这个作为示例（我会在评论中这样做，但在这里看起来更好）：

所以我把它作为我的默认命名空间：

namespace RelatedData.Loader

但我还添加了一个名为：

 public class RelatedData
{
}

因为当类名使用 Add Service Reference 生成代理时，它与命名空间的一部分匹配，所以会感到困惑。

这里的答案是重命名我的班级：

 public class RelatedDataItem
于 2012-12-12T22:26:47.637 回答
18

啊，我终于找到了原因。

我正在处理一个非常大的第三方 WCF API 并且......他们的命名空间之一是LameCompany.System(!!) Carnage 然后随之而来......

啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊

这里要学习的教训是，当 Visual Studio/.net 编译器停止识别 BCL 的System命名空间时，您的项目中有一个命名空间/类型，称为System. 找到它，删除它，射击创建它的开发人员。

于 2011-05-20T08:35:27.973 回答
8

我发现具有类似于您的命名空间的类名会导致这种情况。

尝试重命名您的班级名称

于 2016-10-25T05:48:37.980 回答
1

在更新对服务的引用后，对具有 WCF 服务引用的客户端项目进行了微小更改后，我遇到了 jabu.hlong 和 Simon Needham 描述的 VS2012 的类似问题。我在编译生成的 Reference.cs 文件等时遇到了很多错误（XAML 的生成文件也是如此）。

我选择在我的解决方案中重用来自特定程序集的类型，并且在命名空间中遇到了类似的问题。

我得到的错误是在Reference.cs中使用时找不到重用程序集的命名空间和生成类型的命名空间。两个命名空间的第一部分有共同之处，因为它们来自同一个解决方案。我在解决方案中的命名空间就像appname.tier.technology.project. 两个冲突的命名空间是Appname.Dto.Modulename（重用的程序集）和Appname.Client.Wpf.ServiceName（使用生成类型服务的客户端项目中的命名空间）。

当我在命名空间中创建一个新的实用程序类时，在客户端项目中进行了微小的更改后，问题就出现了Appname.Client.Wpf.Appname。我选择该命名空间是因为 Appname 也是客户端项目中模块的名称。这似乎使编译器感到困惑，并且无法解析生成的 Reference.cs 中的两个命名空间。在更改实用程序类的命名空间以避免在其中使用两个相同的部分并更新服务引用后，Reference.cs 中的编译器错误消失了。

于 2017-09-14T08:42:12.207 回答
1

我尝试了不同的东西（并在添加服务引用时尝试了不同的命名空间），但除了这个蛮力修复之外，没有什么对我有用 - 在我的情况下它没问题，但我知道它很难看（如果你使用“更新”，则需要重复参考”以后）：

由于 WCF 服务命名空间已添加到您的默认命名空间，因此只需搜索并替换所有提及的新添加的命名空间

MyNamespace.ServiceNamespace

和

ServiceNamespace

在整个解决方案中（当然使用您自己的命名空间），包括自动生成的 Reference.cs 文件。

于 2017-11-08T18:10:23.910 回答
1

基本上，问题是名称冲突，其中一个名称隐藏了另一个名称。一个名为“System”的文件夹或类可以做到这一点，但如果你还有一个与你的项目同名的类，你会看到同样的事情。当然，您可以重命名 reference.cs 中的所有内容，但重命名冲突的类可能会更好。

于 2019-04-05T21:02:45.923 回答
0

我的项目中有一个名为“System”的文件夹（是的，我很愚蠢），这导致了references.cs中的一些问题。

重命名文件夹（和命名空间），解决了这个问题。

于 2018-08-02T13:59:18.790 回答
0

这是我在 VisualStudio 2017 上尝试在测试项目中添加对 Web 服务的引用时解决此问题的方法。

在尝试添加引用、重新构建、关闭、重新打开并在该问题上花费一些时间后，我注意到 VS 已将它创建的用于引用 WS 的文件放在名为“Connected Services”的文件夹中。

我重命名了没有空格的文件夹，然后用文本编辑器打开了文件夹中的所有文件和 csproj，将所有出现的“Connected Services”替换为“ConnectedServices”并重新打开了项目。

然后我添加了对 System.Runtime.Serialization 和 System.ServiceModel 的引用，现在一切正常。

于 2019-08-22T12:58:03.367 回答