Compilation errors in Reference.cs after adding a Service Reference caused by multi-part namespace

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.

Answers


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

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.


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

Try renaming your class name


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.


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.


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.


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.


Need Your Help

How to redirect URLs with trailing slash to the corresponding ones without it?

java spring spring-mvc redirect model-view-controller

Spring MVC (3.0) considers URLs with and without trailing slashes as the same URL.

PHP - sort hash array by key length

php arrays sorting key

I've found a few answers to sorting by value, but not key.