Click here to Skip to main content
15,889,034 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I'm struggling to learn my way around WPF/EF/MVVM and am making some progress, but every now and then Visual Studio claims that "The name "Whatever" does not exist in the clr-namespace "HomeOfWhatever", when clearly, it does! Pointing that out, or even yelling at the screen doesn't seem to help. Nor does cleaning & rebuilding, nor does re-starting VS.

Googling indicates that this error can be caused by a wide variety of things, most of which seem (to my novice's eye) to have little to do with the name or namespace in question.

Rather than random stick-poking at the problem (trying all the assorted "fixes" suggested by Googling), it seems that there ought to be a methodical way of narrowing the problem domain to something manageable. (Meaningful error messages would be a big help here, Microsoft!) (Or maybe the error message IS meaningful, and I just don't know enough yet to interpret it.)

I'm hoping that someone out there can explain what that message is trying to say, what kind of rules might have been violated, and maybe even provide a comprehensive checklist of things to look for. Such as: "Don't try to do this from a network share", "Your class has to have a public, parameterless constructor." "It can't be inside another class", "You have to specifically reference the assembly if it is different from your class's assembly", etc.

Thanks.
Posted
Comments
Sergey Alexandrovich Kryukov 13-Jan-15 13:28pm    
You don't need to troubleshoot anything, this is already done for you. Just use correct type name in first place (now you have to fix them). Reference the assemblies you want to use.
You just need to lean the very basics of .NET: what are the assemblies, how they are created and used, types and type names (full type names), roles of namespace. Do preliminary reading and then ask your questions if something is unclear.
—SA

1 solution

Just because a name exists in a namespace, doesn't mean you can just use it!

Generally speaking (and certainly for beginners) follow the simple rule: one project, one namespace. If you need a second namespace, create a second project (that creates a Class Library) and add a reference to that to the original project together with a using statement in the code files that will use the classes the new project contains.
C#
MyEXEProject                                   MyClassLibraryProject
MyEXEClass.cs                                  MyClassLibrary.cs
using System;                                  using System;
...                                            ...
using MyClassLibrary                           

namespace MyEXEProject                         namespace MyClassLibrary
   {                                              {
   public partial class MyForm: Form              public partial class MyClass
      {                                              {
      MyClass myClass = new MyClass();               
      ...                                            ...
      }                                              }
   }                                              }


Once you have that, you should be able to use the classes from either namespace as if they were in the same one (almost).

What do you have that is different?
 
Share this answer
 
Comments
[no name] 14-Jan-15 16:22pm    
Thanks for the response, OriginalGriff. It is clear and understandable.

I was trying to avoid asking for the solution for a specific problem, but rather for a way to approach solving this kind of problem (Teach a man to fish...), but maybe my question was too general.

Right now I'm tearing my hair over referencing view models from the Window.Resources section of my MainWindow. (I'm using MVVM Light.) I can write <vm:testviewmodel x:key="test">, where TestViewModel is a public class, derived from ViewModelBase, with a constructor that takes an IDataService parameter, and I get the dreaded error referenced above. If I add a public parameterless constructor, VS is happy. And yet the view models that come with the MVVM Light template don't have a parameterless constructor - because they derive from ViewModelBase, which does have one, I assume. But my class also derives from ViewModelBase, so why do I need one?

That error also sometimes shows up in the App.xaml file, where vm:ViewModelLocator ceases to exist in the ViewModel namespace after a clean/rebuild, but then (so far) goes away on its own after correcting other unrelated (as far as I can tell) errors.

I just wish I understood more about what that error is trying to tell me.

Thanks again.
[no name] 14-Jan-15 16:28pm    
Hmm. The code snipett that I included in that comment above seems to have been stripped out. I tried to write "I can write vm:TestViewModel x:Key="test" (in brackets, of course) where TestViewModel is a public....

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900