'CompanyName.Foo' is a 'namespace' but is used like a 'type'

Question

Restatement of the question

I'm resurrecting this question because I just ran into this error again today, and I'm still utterly confused why the C# compiler bothers to check for collisions between namespaces and types in contexts where it makes no sense for a namespace to exist.

If I have...

public Foo MyFoo { get; set; }

...why would the compiler care that Foo is both a namespace and a type? Can you declare a property as a namespace instead of a type?

What is the logic behind the "namespace used like type" compiler error? What problem is this saving me from?

[And how do I tag Eric Lippert? :)]

---

Original Question

---

The problem

I have a project "Foo" with default namespace CompanyName.Foo. I have a database that's also called "Foo".

And when I run SqlMetal.exe on the database, it generates a class CompanyName.Foo.Models.Foo.

Then, when I attempt to create a property with this class as the type, like this...

using CompanyName.Foo.Models;
...
public Foo DataContext { get; set; }

...I get the error:

'CompanyName.Foo' is a 'namespace' but is used like a 'type'.

I am forced to do...

public CompanyName.Foo.Models.Foo Foo { get; set; } // :-(

Questions:

1. Why does this error occur? My property declaration doesn't contain CompanyName, so why is this a problem? Simply put: Foo != CompanyName.Foo. Also, just to be sure, I did a search of my entire solution for namespace Foo and came up with zero hits (if I had actually used a namespace Foo, I could understand getting an error).

2. [answered] Is there any way around fully qualifying Foo every time I want to use it?

3. [answered] Is there any way to get SqlMetal to name the class anything other than Foo (w/o changing the name of my database)? I can change the namespace using a switch, but I don't know of a way to change the actual class name.

Update

Still seeking an answer to (1).

O.K.W. nailed (2) & (3).

Usings

A request was made for all my using statements:

using System;
using System.ComponentModel;
using System.Data.Linq;
using System.Linq;
using MyCompany.Foo.Models;

Solution 1

how do I tag Eric Lippert?

If you have something you want brought to my attention you can use the "contact" link on my blog.

I'm still utterly confused why the C# compiler bothers to check for collisions between namespaces and types in contexts where it makes no sense for a namespace to exist.

Indeed, the rules here are tricky. Coincidentally, two weeks ago I wrote and posted a series of blog articles about some of these issues closely related to this very issue; they'll actually go live in early March. Watch the blog for details.

UPDATE: The articles mentioned above are here:

Link

Why does this error occur?

Let me rephrase the question into several questions.

What sections of the specification justify the production of this error?

I think that's already been covered satisfactorily in other answers. The type resolution algorithm is extremely well-specified. But just to sum up: being inside something of the right name "binds more tightly" than using something of the right name from the outside. When you say:

using XYZ;
namespace ABC.DEF
{
    class GHI : DEF { }
}

that is the same as

using XYZ;
namespace ABC
{
    namespace DEF 
    {
        class GHI : DEF { }
    }
}

So now we must determine the meaning of DEF. We go from inside to outside. Is there a type parameter of GHI called DEF? No. Look at the container. Is there a member of DEF called DEF? No. Look at the container. Is there a member of ABC called DEF? YES. We're done; we have determined the meaning of DEF, it is a namespace. We discover the meaning of DEF before we ask "does XYZ have a member DEF?"

What design principles influence this design?

One design principle is "names mean the same thing no matter how you use them". The language does not 100% obey this principle; there are situations in which the same name can be used to refer to two different things in the same code. But in general, we strive for a situation where when you see "Foo" two times in the same context, it means the same thing. (See my article on The Color Color Problem for some details on this, as well as my articles on identifying violations of the "simple name" rules.)

One design principle is "no backtracking". We do not ever say in C# "I see that you used a name to refer to something that is not legal to refer to in this context. Let me abandon the result of name binding and start over, looking for something that might work."

A larger principle that underlies the "no backtracking" principle is that C# is not a "guess what the user meant" language. You wrote a program where the best possible binding of an identifier identified a namespace when a type was expected. There are two possibilities. Possibility one: you've made an error that you want to be told about so that you can take action to correct it. Possibility two: you meant for a less-good binding to be the one we choose, and so we should guess from amongst all the possible less-good bindings to figure out which one you probably meant.

That's a good design principle in languages like JScript -- JScript is all about muddling on through when the developer does something crazy. C# is not that kind of language; the feedback we get loud and clear from our developers is tell me when something is broken so I can fix it.

The thing about "no backtracking" is that it makes the language much easier to understand. Suppose you have something like this mess:

namespace XYZ.DEF
{
    public class GHI {}
}
namespace QRS.DEF.GHI
{
    public class JKL { }
}
...
using QRS;
namespace TUV 
{
  using XYZ;
  namespace ABC
  {
    namespace DEF 
    {
        class GHI { }
        class MNO : DEF.GHI.JKL { }
    }
  }
}

Work out the base type of MNO. With no backtracking we say "DEF is ABC.DEF". Therefore GHI is ABC.DEF.GHI. Therefore JKL is ABC.DEF.GHI.JKL, which does not exist, error. You must fix the error by giving a type name that lets the compiler identify which DEF you meant.

If we had backtracking, what would we have to do? We get that error, and then we backtrack. Does XYZ contain a DEF? Yes. Does it contain a GHI? Yes. Does it contain a JKL? No. Backtrack again. Does QRS contain an DEF.GHI.JKL? Yes.

That works, but can we logically conclude from the fact that it works that it is the one the user meant?

Who the heck knows in this crazy siutation? We got all kinds of good bindings in there that then went bad very late in the game. The idea that we stumbled upon the desired answer after going down many blind alleys seems highly suspect.

The correct thing to do here is not to backtrack multiple times and try out all kinds of worse bindings for every stage of the lookup. The correct thing to do is to say "buddy, the best possible match for this lookup gives nonsensical results; give me something less ambiguous to work with here please."

An unfortunate fact about writing a language where the compiler by design complains loudly if the best match is something that doesn't work, is that developers frequently say "well, sure, in general I want the compiler to point out all my mistakes -- or, rather, all my coworker's mistakes. But for this specific case, I know what I am doing, so please, compiler, do what I mean, not what I say."

Trouble is, you can't have it both ways. You can't have both a compiler that both enforces rigid rules that make it highly likely that suspicious code will be aggressively identified as erroneous and allow crazy code via compiler heuristics that figure out "what I really meant" when you write something that the compiler quite rightly sees as ambiguous or wrong.

For an object lesson in how lots of pro devs vehemently dislike the effects of a language design that aggressively identifies errors rather than guessing that the developer meant for the worse result to be chosen, see the 116 comments to this article on a minor and rather unimportant aspect of overload resolution:

(Note that I am no longer responding to comments on this issue; I've explained my position over ten times. If all those explanations are not convincing, that's because I'm not a very good convincer.)

And finally, if you really want to test your understanding of how the name resolution rules work in C#, try out this little puzzle. Almost everyone gets it wrong, or gets it right for the wrong reasons. The answer is here.

Solution 2

1. The clash is between namespace CompanyName.Foo and CompanyName.Foo.Models.Foo, and not Foo. I'm not exactly sure how/why the compiler can't distinguish both though.

2. You can try using namespace alias to shorten full qualifying Foo
   e.g. using coyModels = CompanyName.Foo.Models

3. From the reference, seems like you can use /context:<type> and /namespace:<name> to specify the data context class (instead of using table name) and namespace.

Solution 3

C# compiler doesn't compile when there is an ambiguity between a class and a namespace with the same name. Unfortunately you just have to namespace the class explicitly or rename the database. In your case the compiler didn't even get to the conflict, it died after resolving Foo as a namespace.

Whenever you have something like this:

using CompanyName.Foo.Models;

namespace CompanyName.Foo {
    class Test {
        public Foo Model { get; set; } // error CS0118: 'CompanyName.Foo' is a 'namespace' but is used like a 'type'
        public Foo1 Model { get; set; } //OK
    }
}

namespace CompanyName.Foo.Models {
    class Foo1 {
    }
    class Foo {
    }
}

What actually happens is every preceeding level of the namespace is implicitly imported at each level. This makes sense since the nested namespace syntax using dot is the same as nesting namespaces:

namespace CompanyName {
    using CompanyName; //<--using1 - Implicit using, since we should be able to access anything within CompanyName implicitly.
    namespace Foo {
        using CompanyName.Foo; //<-- using2 Same as above
        class Test {
            public Foo Model { get; set; } //At this stage due to using1 Foo is actually CompanyName.Foo, hence the compiler error
        }
    }
}

So inside class Test there are two implicit usings:

using CompanyName;
using CompanyName.Foo;

Hence Foo is resolved to the namespace hence the error.

EDIT Good point. I've dug this up from MSDN:

The meaning of a namespace-or-type-name is determined as follows:

• If the namespace-or-type-name consists of a single identifier:

  • If the namespace-or-type-name appears within the body of a class or struct declaration, then starting with that class or struct declaration and continuing with each enclosing class or struct declaration (if any), if a member with the given name exists, is accessible, and denotes a type, then the namespace-or-type-name refers to that member. Note that non-type members (constants, fields, methods, properties, indexers, operators, instance constructors, destructors, and static constructors) are ignored when determining the meaning of a namespace-or-type-name.

  • Otherwise, starting with the namespace in which the namespace-or-type-name occurs, continuing with each enclosing namespace (if any), and ending with the global namespace, the following steps are evaluated until an entity is located:

  • If the namespace contains a namespace member with the given name, then the namespace-or-type-name refers to that member and, depending on the member, is classified as a namespace or a type.

  • Otherwise, if the namespace has a corresponding namespace declaration enclosing the location where the namespace-or-type-name occurs, then:

  • If the namespace declaration contains a using-alias-directive that associates the given name with an imported namespace or type, then the namespace-or-type-name refers to that namespace or type.

  • Otherwise, if the namespaces imported by the using-namespace-directives of the namespace declaration contain exactly one type with the given name, then the namespace-or-type-name refers to that type.
    ...

(Bolding is mine) This means that when resolving Foo, matching it against CompanyName.Foo (first bold bit) happens before matching it against the using directive(second bold build).

Solution 4

why can't you just do

using CompanyName.Foo; 
... 
public Models.Foo DataContext { get; set; } 

Solution 5

I had this issue pop up when I was referencing a class in a separate class library, where its type had the same name as the root of the namespace. Initially, when referencing this type in a separate console app project, there was no problem, everything compiled fine. However the reference from a Windows Service project was generating the is a 'namespace' but is used like a 'type'. message. Turns out the Windows Service Project had its Target Framework set to ".NET Framework 4 Client Profile". Changing this to ".NET Framework 4" eliminated the error. Hopefully this helps someone in a similar situation.

View more solutions

Comments

[tster]

Can you post all your using lines?

[devuxer]

@tster - I added these to the end of my question.

[Brett Ryan]

I hate the fact that the C# compiler can't distinguish the difference, it should be able to identify the context that the name is being used for a class name and not even evaluate namespaces. I hope this is resolved in C# 4.0 as it's one heck of a burden.

[devuxer]

Thanks for making me look at the reference again. I don't know how I missed /context. Also, namespace aliases are a nice trick--didn't know you could do that. I'm not following your answer for (1) though. How can there be a clash between two things that don't match each other?

[devuxer]

...but the class and namespace don't have the same name. That's the whole reason for my question. Foo != CompanyName.Foo.

[o.k.w]

I guess /context is not very inituitive, I would expect /class or /type, yea? For my answer to point 1, I think you can just ignore that, I'm puzzled by it too.

[devuxer]

Thanks for your explanation, but it doesn't quite answer the question of why the compiler thinks Foo is referring to a namespace when it processes public Foo DataContext { get; set; }. Why would the compiler assume I'm trying to type a property as a namespace rather than as a type? That's the part that doesn't make sense. The compiler should see public SomeType PropertyName { get; set; } and do a check to see if there are any types matching SomeType--not check to see if SomeType is a namespace.

[devuxer]

Igor, thanks again. This appears to be an explanation of what the compiler is doing, but it doesn't explain why. Why would it match to a namespace before a type when only a single identifier is present? This doesn't make sense to me.

[Igor Zevaka]

Well, it's in the language spec, so there must be a good reason for that. My take is that it is for consistency, so that Foo always resolves to the same thing, be that namespace or class. Otherwaise you would end up with the same identifier meaning different things depending on the context it's been used in, especially considering the fluent nature of the whole namespace-or-class thing.

[devuxer]

Scott, Just as with Igor's answer, I'm still wondering: Can you declare a property as a namespace instead of a type? Could you have public System IAmANamespace { get; set; }? Because if you can't, I don't care if the compiler can find a namespace called System. I only care that it can't find a type called System. In my case, there is a type called Foo in the current context. Why can't the compiler find it and use it?

[scottm]

You can't use a namespace instead of a type, that's exactly what the error is telling you. You may be mistaken in thinking that a Foo object has be declared in the same context. Try right clicking the class name that's giving you the error, and see if you get a "Resolve" option in the context menu. It should list the corresponding class/namespace matches.

[devuxer]

scott, I know that's what the error is telling me...what I'm trying to say is that there is no reason for the error to exist. Basically, what we have is a tie and I think the C# designers have chosen the wrong tie-breaker. If you have a slot that only a type can fit into, then a good design would break the tie by going with the type, not going with the namespace and then telling me I've made an error.

[scottm]

@DanM, my examples show what you are describing. In the first example, no Foo object (other than the namespace) is defined. In that context, you get the error. In the second example, a Foo object is defined, and the compiler recognizes that fact.

[devuxer]

@Scott, what namespace does DataContextClass belong to in your example?

[scottm]

In the example, it's in the global namespace of the file. You could just as easily wrap it in it's own namespace and achieve the same effect.

[devuxer]

Eric, This is exactly the answer I was seeking, thank you. I agree with you that "you can't have it both ways." I do want the compiler to complain loudly if I've made an error, and I think it's reasonable that the compiler doesn't go hunting for a possible match when the "closest" match doesn't work. It would be nice, however, if there were a way to explicitly say what I mean without having to qualify every instance of Foo with either a full namespace path or an alias. I'm thinking something like using Foo as CompanyName.Models.Foo or alias Foo = CompanyName.Models.Foo.

[jrista]

@DanM: "How can there be a clash between two things that don't match each other". Note that you can reference things through partial namespaces in C#. If you are writing code in the CompanyName namespace, you can reference something in the Foo child namespace via Foo.Something, rather than CompanyName.Foo.Something. As such, if you use CompanyName.Foo.Models, the class Foo in that namespace clashes with the "Foo" child namespace that you can also access. The compiler does not know whether you want the Foo child namespace or the Foo class for your DataContext property.

[devuxer]

Soon after posting the above comment, I learned that the feature I was seeking already existed. C# lets you alias not just namespaces but also types. So, for the given example, I could have put something like using FooModel = CompanyName.Foo.Models.Foo; at the top of the class, and declared the property public FooModel MyFoo.

[Eric Lippert]

@DanM: Indeed, however there are a few unfortunate restrictions. First, the aliasing directive is only scoped to a file or lexical namespace body; you have to repeat the alias in every file that you use it in. Second, it does not work well with generic types. using IntList = System.Collections.Generic.List<System.Int32>; works, but using Foo<T> = Bar<T>; does not. Third, IntelliSense sometimes gets it wrong; if you have something like using HANDLE=System.Int32; then IntelliSense will sometimes use HANDLE instead of int when you don't expect it to.

[chiwal]

Your first point cleared it up for me. If you're just using Foo all by itself (as a type), the compiler won't know whether to use the namespace CompanyName.Foo, or your class CompanyName.Foo.Models.Foo. Of course one might ask: "Then why can't the compiler be smart enough to know when I'm using it as a type like: public Foo GetFoo()"? Obviously this won't work as a namespace, so why not interpret it as a type?. Maybe Eric answered it already and I'm just being too lazy to read his really long answer. :)