在将第一个“服务引用”添加到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::以强制编译器做正确的事情。实际上，如果“添加服务引用”向导使用T4模板，我可能只是修改那些以在源头嵌入我的变通方法。
我真的很想了解这里发生了什么以及多部分命名空间导致此问题的原因。据推测，命名空间比我想象的更多。其次，我希望找到一个更好的解决方案，而不是每次添加服务引用或使用某些T4模板时执行全局查找/替换。
我发现这里的答案有点不清楚，所以我想我会把它作为一个例子添加（我会在评论中这样做，但在这里看起来更好）：
所以我把它作为我的默认命名空间：
namespace RelatedData.Loader
但我还添加了一个名为的类：
public class RelatedData { }
由于类名称在使用“添加服务引用”生成代理时与命名空间的一部分匹配，因此会混淆。
这里的答案是重命名我的课程：
public class RelatedDataItem
啊，我最终找到了原因。
我正在与一个非常大的第三方WCF API进行对抗......他们的一个名称空间是LameCompany.System（!!）然后随后的大屠杀...
Arrrgghhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
这里要学习的教训是当Visual Studio / .net编译器停止识别BCL的System命名空间时，您的项目名称为System。找到它，删除它，拍摄创建它的开发人员。
我发现有一个类似于你的命名空间的类名会导致这种情况。
尝试重命名您的班级名称
我在jabu.hlong和Simon Needham描述的VS2012中遇到了类似的问题，在更新对服务的引用之后，客户端项目中有一些引用了WCF服务。编译生成的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中的编译器错误消失了。
我尝试了不同的东西（并在添加服务引用时尝试了不同的命名空间），但除了这种暴力修复之外没有任何作用 - 在我的情况下它没关系但是我知道它很难看（如果你使用“需要重复”）参考“将来”：
由于WCF服务命名空间已添加到您的默认命名空间，因此只需搜索并替换新添加的所有提及
MyNamespace.ServiceNamespace
同
ServiceNamespace
在整个解决方案中（当然使用您自己的命名空间），包括自动生成的Reference.cs文件。
我的项目中有一个名为“System”的文件夹（是的，我非常愚蠢），这引起了references.cs中的一些问题。
重命名文件夹（和命名空间），修复了问题。
基本上，问题是名称冲突，其中一个名称隐藏另一个名称。名为“System”的文件夹或类可以执行此操作，但如果您还有一个与项目同名的类，则会看到相同的内容。当然，您可以重命名reference.cs中的所有内容，但最好重命名冲突的类。