添加服务引用后,引用.cs中的编译错误由多部分命名空间导致
本文关键字:引用 多部 错误 命名空间 服务 cs 添加 编译 | 更新日期: 2023-09-27 17:57:12
在Visual Studio 2010中将我的第一个"服务引用"添加到客户端项目时,我遇到了这个奇怪的命名空间问题。
如果我项目的默认命名空间使用两个或多个部分,例如 MyCompany.MyApp
,在添加服务引用时.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
编译器的行为,并将系统命名空间引用识别为 .net 的系统命名空间的降级。
我现在正在使用不同的解决方法,因为我真的很想保留我的多部分命名空间。我目前的替代方法是在 System 命名空间引用前面附加global::
,以强制编译器执行正确的操作。事实上,如果"添加服务引用"向导使用 T4 模板,我可能只是修改这些模板以在源中嵌入我的解决方法。
问题
我真的很想了解这里发生了什么以及为什么多部分命名空间会导致此问题。大概命名空间比我想象的要多。其次,真的想找出一个更好的解决方案,而不是每次添加服务引用或使用一些 T4 模板时执行全局查找/替换。
我发现这里的答案有些不清楚,所以我想我会添加这个作为示例(我会在评论中这样做,但在这里看起来更好):
所以我把它作为我的默认命名空间:
namespace RelatedData.Loader
但我还添加了一个名为的类:
public class RelatedData { }
由于类名在使用"添加服务引用"生成代理时与命名空间的一部分匹配,因此会感到困惑。
这里的答案是重命名我的类:
public class RelatedDataItem
啊,好吧,我最终找到了原因。
我正在反对一个非常大的第三方 WCF API,并且......他们的命名空间之一是LameCompany.System
(!!!然后大屠杀随之而来...
啊
这里要学习的教训是,当Visual Studio/.net编译器停止识别BCL的System
命名空间时,项目中有一个名为System
的命名空间/类型。找到它,删除它,拍摄创建它的开发人员。
我发现具有与您的命名空间相似的类名会导致这种情况。
尝试重命名类名
在更新对服务的引用后,在对具有对 WCF 服务的引用的客户端项目中进行了微小更改后,我在 jabu.hlong 和 Simon Needham 描述的 VS2012 中遇到了类似的问题。我在编译引用时遇到很多错误.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"的文件夹或类可以执行此操作,但是如果您还有一个与项目同名的类,则会看到相同的内容。当然,您可以重命名引用中的所有内容.cs,但重命名冲突的类可能更好。
我的项目中有一个名为"系统"的文件夹(是的,我非常愚蠢),这导致了参考文献中的一些问题.cs。
重命名文件夹(和命名空间)修复了此问题。
以下是我在 VisualStudio 2017 上尝试在测试项目中添加对 Web 服务的引用时解决此问题的方法。
在尝试添加引用、重建、关闭、重新打开并花一些时间解决这个问题后,我注意到 VS 已将其创建的引用 WS 的文件放在名为"连接服务"的文件夹中。
我重命名了没有空格的文件夹,然后用文本编辑器打开了文件夹和csproj中的所有文件,将所有出现的"连接服务"替换为"连接服务"并重新打开项目。
然后,我添加了对System.Runtime.Serialization和System.ServiceModel的引用,现在一切正常。
这是 Visual Studio 中的一个错误(仍然是 2022 版)。 若要修复,请删除引用.cs文件中的命名空间。因此,如果您的命名空间是"myapplication",而您的服务是"myservice",您将在reference.cs文件中看到myapplication.myservice。 只需删除所有位置的"myapplication.",并确保它不会再次自动生成(以免您必须重新删除所有内容)。