在将第一个“服务引用”添加到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
然后编译器行为并将系统命名空间引用识别为.net的System命名空间的解除。
我现在正在使用不同的解决方法,因为我真的想保留我的多部分命名空间。我当前的替代方法是在System命名空间引用前面附加global::
以强制编译器执行正确的操作。事实上,如果“添加服务引用”向导使用T4模板,我可能只是修改那些以在源头嵌入我的变通方法。
我真的很想了解这里发生了什么以及多部分命名空间导致此问题的原因。据推测,命名空间比我想象的更多。其次,我希望找到一个更好的解决方案,而不是每次添加服务引用或使用某些T4模板时执行全局查找/替换。
答案 0 :(得分:26)
我发现这里的答案有点不清楚,所以我想我会把它作为一个例子添加(我会在评论中这样做,但在这里看起来更好):
所以我把它作为我的默认命名空间:
namespace RelatedData.Loader
但我还添加了一个名为:
的类public class RelatedData { }
由于类名称在使用“添加服务引用”生成代理时与名称空间的一部分匹配,因此会混淆。
这里的答案是重命名我的课程:
public class RelatedDataItem
答案 1 :(得分:16)
啊,我最终找到了原因。
我正在攻击一个非常大的第三方WCF API,并且......其中一个命名空间是LameCompany.System
(!!)然后随后出现了大屠杀......
Arrrgghhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
这里要学习的教训是,当Visual Studio / .net编译器停止识别BCL的System
命名空间时,您的项目中名称为System
的命名空间/类型。找到它,删除它,拍摄创建它的开发人员。
答案 2 :(得分:8)
我发现拥有类似于你的命名空间的类名会导致这种情况。
尝试重命名您的班级名称
答案 3 :(得分:1)
我在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中的编译器错误消失了。
答案 4 :(得分:1)
我尝试了不同的东西(并且在添加服务引用时尝试了不同的命名空间),但除了这种强力修复之外没有任何作用 - 在我的情况下它没关系但是我知道它很难看(如果你需要重复将来使用“更新参考”):
由于WCF服务命名空间已添加到您的默认命名空间,因此只需搜索并替换新添加的所有提及
MyNamespace.ServiceNamespace
带
ServiceNamespace
在整个解决方案中(当然使用您自己的命名空间),包括自动生成的Reference.cs文件。
答案 5 :(得分:0)
我的项目中有一个名为“系统”的文件夹(是的,对我来说很愚蠢),这在references.cs中引起了一些问题。
重命名文件夹(和名称空间),解决了该问题。
答案 6 :(得分:0)
基本上,问题在于名称冲突,其中一个名称隐藏了另一个。名为“ System”的文件夹或类可以做到这一点,但是如果您还有一个与项目名称相同的类,那么您将看到相同的内容。当然,您可以重命名reference.cs中的所有内容,但是最好重命名冲突的类。
答案 7 :(得分:0)
这是我在Visual Studio 2017上解决此问题的方法,试图在测试项目中添加对Web服务的引用。
尝试添加引用,重建,关闭,重新打开并花一些时间解决问题后,我注意到VS已将其创建的文件引用WS放在名为“ Connected Services”的文件夹中。
我将文件夹重命名为没有空格,然后使用文本编辑器打开了文件夹中的所有文件和csproj,将所有出现的“ Connected Services”替换为“ ConnectedServices”,然后重新打开了项目。
然后我添加了对System.Runtime.Serialization和System.ServiceModel的引用,现在一切正常。