添加服务引用后,Reference.cs 中由多部分命名空间导致的编译错误

发布于 2024-11-09 01:53:57 字数 945 浏览 0 评论 0原文

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

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

Reference.cs 文件将充满编译错误,因为编译器开始将 System 命名空间视为 MyCompany.MyApp 命名空间的子成员。你会得到很多类似以下的错误:

命名空间“MyCompany.MyApp.System”中不存在类型或命名空间名称“Runtime”...

如果我将 Reference.cs 文件顶部的命名空间修改为简单的内容,例如MyCompanyMyApp.ServiceRefernceName 然后编译器将系统命名空间引用识别为 .net 系统命名空间的声明。

我现在正在使用不同的解决方法,因为我真的想保留我的多部分命名空间。我当前的替代方案是在系统名称空间引用前面附加 global:: ,以强制编译器执行正确的操作。事实上,如果“添加服务引用”向导使用 T4 模板,我可能只需修改这些模板即可将我的解决方法嵌入到源中。

问题

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

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

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.

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:

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

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.

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.

Questions

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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(9

生死何惧 2024-11-16 01:53:57

我发现这里的答案有些不清楚,所以我想我会添加这个作为示例(我会在注释中这样做,但在这里看起来更好):

所以我将其作为我的默认命名空间:

namespace RelatedData.Loader

但我还添加了一个名为:

公共类RelatedData
{
}

由于类名与命名空间的一部分相匹配,因此在使用“添加服务引用”生成代理时会感到困惑。

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

 public class RelatedDataItem

I found the answer here somewhat unclear, so I thought I would add this as an example (I would do it in the comments but it looks better here):

So I have this as my default namespace:

namespace RelatedData.Loader

But I also add a class named:

 public class RelatedData
{
}

Because the class name matches a portion of the namespace when it generates your proxy with Add Service Reference it gets confused.

The answer here was to rename my class:

 public class RelatedDataItem
橘虞初梦 2024-11-16 01:53:57

啊,好吧,我最终找到了原因。

我正在针对一个非常大的第三方 WCF API 工作,并且...他们的命名空间之一是 LameCompany.System (!!) 大屠杀随之而来...

Arrrgghhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

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

Ahh well I found the cause eventually.

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

Arrrgghhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

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.

阳光下的泡沫是彩色的 2024-11-16 01:53:57

我发现类名与你的命名空间相似会导致这种情况。

尝试重命名您的班级名称

I found that having a class name similar to your namespace causes this.

Try renaming your class name

转瞬即逝 2024-11-16 01:53:57

在更新对服务的引用后,对包含对 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 中的编译器错误消失了。

I ran into a similar issue with VS2012 described by jabu.hlong and Simon Needham after minor changes in the client project that has the references to the WCF services after updating the reference to the services. I got lots of errors compiling the Reference.cs files generated and so on (the generated files of the XAML as well).

I have selected to reuse types from specific assemblies in my solution and got a similar problems with the namespaces.

The error I get is that the namespace of the reused assembly and the namespace of the generated types can not be found when used in the Reference.cs. Both namespaces have in common the first parts, as they are from the same solution. My namespaces in the solution are like appname.tier.technology.project. Both conflicting namespaces are Appname.Dto.Modulename (the reused assembly) and Appname.Client.Wpf.ServiceName (the namespace in the client project using the services for the generated types).

The problem arises after a minor change in the client project, when I created a new utility class in the namespace Appname.Client.Wpf.Appname. I choose that namespace because the Appname is also the name of a module in the client project. This seems to confuse the compiler and can not resolve both namespaces in the generated Reference.cs. After changing the namespace of the utility class to avoid using two identical parts in it and updating the service reference, the compiler errors in Reference.cs dissapears.

離人涙 2024-11-16 01:53:57

我尝试了不同的事情(并在添加服务引用时尝试了不同的命名空间),但除了这个强力修复之外,没有任何对我有用的东西 - 在我的情况下它还可以,但我知道它很丑陋(如果您使用“更新”,则需要重复参考”):

由于 WCF 服务命名空间已添加到您的默认命名空间中,因此只需在整个解决方案中搜索并替换所有提及的新添加的内容即可

MyNamespace.ServiceNamespace

ServiceNamespace

当然使用您自己的命名空间),包括自动生成的参考。 .cs 文件。

I tried different things (and tried different namespaces when adding the service reference), but nothing worked for me except this brute force fix - in my case it was OK but I am aware it's ugly (and needs to be repeated if you use "Update Reference" in the future):

Since the WCF service namespace is added to your default namespace, just search and replace all mentions of the newly added

MyNamespace.ServiceNamespace

with

ServiceNamespace

in the whole solution (use your own namespaces of course), including the auto-generated Reference.cs file.

栀梦 2024-11-16 01:53:57

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

Basically, the problem is a name conflict where one name is hiding another. A folder or class named "System" can do that, but if you also have a class with the same name as your project, you'll see the same thing. Sure, you can rename everything in the reference.cs, but it's probably better to rename your conflicting class.

夏了南城 2024-11-16 01:53:57

这是 Visual Studio 中的一个错误(2022 版本仍然存在)。要修复此问题,请删除 reference.cs 文件中的命名空间。因此,如果您的命名空间是“myapplication”并且您的服务是“myservice”,您将在reference.cs 文件中看到myapplication.myservice。只需删除“我的应用程序”即可。并确保它不会再次自动生成(以免您必须重新删除所有内容)。

This is a bug in Visual Studio (still is at version 2022). To fix, remove the namespace in the reference.cs file. So if your namespace is "myapplication" and your service is "myservice", you'll see myapplication.myservice in the reference.cs file. just delete "myapplication." everywhere and make sure it isn't auto-generated again (lest you have to re-delete everything).

逆夏时光 2024-11-16 01:53:57

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

重命名文件夹(和命名空间),解决了问题。

I had folder in my project called "System" (yes, very stupid of me) and that caused some issues in the references.cs.

Renaming the folder (and the namespace), fixed the issue.

jJeQQOZ5 2024-11-16 01:53:57

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

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

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

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

Here is how I solve this issue on VisualStudio 2017 trying to add a reference to a web service in a test project.

After trying adding the references, rebuilding, closing, reopening and spending some time on the issue, I noticed that VS had put the files it creates to reference the WS in a folder named "Connected Services".

I renamed the folder without the space then opened all the files in the folder and the csproj with a text editor, replaced all the occurrences of "Connected Services" to "ConnectedServices" and reopened the project.

I then added references to System.Runtime.Serialization and System.ServiceModel and everything now works fine.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文