编译错误Reference.cs增加引起的多部分的命名空间服务引用后, [英] Compilation errors in Reference.cs after adding a Service Reference caused by multi-part namespace

查看:165
本文介绍了编译错误Reference.cs增加引起的多部分的命名空间服务引用后,的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我将我的第一个服务引用在Visual Studio 2010中的客户机项目时,打这个奇怪的名字空间的问题。

I hit this weird namespace issue when adding my first 'Service Reference' to a client project in Visual Studio 2010.

如果我的项目的默认命名空间使用两个或两个以上的部分,如 MyCompany.MyApp 然后添加一个服务引用创建Reference.cs文件,其中包含命名空间时, MyCompany.MyApp.ServiceReferenceName 有很多自动根code具有完全限定名称,例如: System.SerializableAttribute System.Runtime.Serialization.DataContractAttribute

If my project's default namespace uses two or more parts, e.g. MyCompany.MyApp then when adding a Service Reference a Reference.cs file is created containing the namespace MyCompany.MyApp.ServiceReferenceName with a lot of auto-gen code with fully qualified names, e.g. System.SerializableAttribute, System.Runtime.Serialization.DataContractAttribute.

由于编译器开始处理系统命名空间的子 MyCompany.MyApp 命名空间的成员的Reference.cs文件将被完全编译错误。

The Reference.cs file will be full of compilation errors because the compiler starts treating the System namespace as sub member of the MyCompany.MyApp namespace. You get an awful lot of errors along the lines of:

的类型或命名空间名称运行并没有在命名空间存在'MyCompany.MyApp.System...

如果我修改了命名空间的Reference.cs的顶层文件简单的东西,如: MyCompanyMyApp.ServiceRefernceName 则编译器的行为,并认识到系统命名空间引用为.NET的系统命名空间的decleration。

If I amend the namespace at the top of the Reference.cs file to something simple, e.g. MyCompanyMyApp.ServiceRefernceName then the compiler behaves and recognises the System namespace references as decleration of .net's System namespace.

我使用的是不同的解决方法,现在我真的想保持我的多部分的命名空间。我现在的选择是追加全球:: System命名空间中引用前强制编译做正确的事情。事实上,如果'添加服务引用向导使用T4模板我可能只修改那些嵌入我的解决方法在源头。

I'm using a different workaround for now as I really want to keep my multi-part namespaces. My current alternative is to append global:: in front of the System namespace references to force the complier to do the right thing. In fact, if the 'Add Service Reference' wizard uses T4 templates I may just amend those to embed my workaround at the source.

我真的很想了解这是怎么回事,为什么一个多部分的命名空间会导致此问题。 presumably有更多的命名空间比我想象的。其次,真的想找出一个更好的解决方案比执行全局查找/替换我每次添加一个服务引用,或用一些T4模板碴左右。

I'd really like to understand what's going on here and why a multi-part namespace causes this issue. Presumably there's more to namespaces than I thought. Secondly, would really like to work out a better solution than performing a global Find/Replace every time I add a Service Reference or mucking around with some T4 templates.

推荐答案

啊还有我找到了原因也说不定。

Ahh well I found the cause eventually.

我的工作对一个非常大的第三方WCF API和......他们的名字空间中的一个是 LameCompany.System (!!)大屠杀,然后随之而来......

I'm working against a very large third party WCF API and ... one of their namespaces is LameCompany.System (!!) Carnage then ensues...

Arrrgghhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

Arrrgghhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

要在这里学到的教训是,当的Visual Studio / .NET编译器终止确认该BCL的系统命名空间,你有一个命名空间/类型的项目中的一个名为系统。找到它,删除它,拍创建它的开发者。

The lesson to learn here is when Visual Studio/.net compiler stops recognising the BCL's System namespace you have a namespace/type in your project called System. Find it, remove it, shoot the developer that created it.

这篇关于编译错误Reference.cs增加引起的多部分的命名空间服务引用后,的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆