I have a problem here. I have a class library namely ClLib, and has the following 8 cs files.
Express (parent class)
- 1E1
- 1E2
- 1E3
Normal (parent class)
- 1N1
- 1N2
- 1N3
Also, a method is also included in each 8 class file. For example,
public class 1E1:Express
{
public int subtractNumExp1E1(int firstNum, int secNum)
{
return firstNum - secNum;
}
}
The 1E1:Express is used to display the relationship between the parent class(Express) and subclass (1E1).
I have also created a Windows App in Visual Studio, and I need to create a directive like "using ClLib.Express.1E1". How do I go about it? I am stuck in this situation whereby when I want to change the namespace of 1E1 from "namespace ClLib" to "namespace ClLib.Express.1E1". An error occurs, as the namespace ClLib has already contain one definition for Express.
A great thanks and appreciation in advance for all kind souls who are willing to help me:)
You can't have a type and a namespace with the same name ("CILib.Express").
If you want a CILib.Express namespace, the simplest option is to move/rename the CILib.Express type.
You can, however, also have nested types. You could, for example, have:
namespace CILib {
public class Express {
public class SomeType {}
}
}
If separate files are a concern:
file 1:
namespace CILib {
public partial class Express {
// "Express" code
}
}
file 2:
namespace CILib {
public partial class Express {
public class SomeType {
// "SomeType" code
}
}
}
However, using directives only relate to namespaces; I don't think you could have using CILib.Express, as that is a type not a namespace.
In that case you just have to delete the namespace ClLib and make sure that there is exactly one copy of ClLib.Express.1E1
P/S: Are you sure that the proper namespace is ClLib.Express.1E1? 1E1 is a cs file, and it's usually a class. So you don't have to write using ClLib.Express, that would be sufficient.
I think there is confusion around the namespace and base class.
Namespace: ClLib.Express
Class: public class 1E1:Express
Rename your base class to ExpressBase to differentiate it.
If you need to reference the namespace:
using ClLib.Express
Hope I have understood your project structure!
Related
I'm pretty new to the whole C# thing and I'm a bit used to C++ with the header files. So I hope this isn't the dumbest question.
How can I import the MainWindow.cs into the MainWindow.xaml.cs?
I thought I could just use using MainWindow.cs
In .Net you can use any class in the same project, or in any referenced project or dll. You never need to worry about header files. The .Net assemblies themselves contain all the type information needed to use them.
Type disambiguation is done with namespaces, you should typically place types in a namespace like ProjectName.Folder I.e.
namespace MyProject.Quelldateien.Inc{
public class MainWindow{
...
}
}
In your code file you need to use the full namespace when refering to a type, i.e. MyProject.Quelldateien.Inc.MainWindow, or add a using statement at the top of your file:
using MyProject.Quelldateien.Inc
namespace MyProject{
public class MyClass{
...
}
}
Note that you should usually try to avoid using the same name for classes, since this would require using the full namespace to refer to your type. A common convention is for your name your xaml-classes MyMainView and the view model class (containing properties you bind to) as MyMainViewModel. And place this in separate folders.
Also note that some refactoring tools can add namespaces automatically, so I almost never write out using MyProject.Quelldateien.Inc, I just write my type name, and accept the namespace suggestion by the tool.
in the MainWindow.cs see the namespace. like:
namespace Quelldateien.inc
{
internal class MainWindow
{
}
}
then use:
using Quelldateien.inc;
Every now and then I run into the error The namespace 'My.SuperAwesome.Namespace' already contains a definition for 'SomeClass'
Which is fine, I understand namespaces and that I have conflicting class definitions. The problem is, how do I find that conflicting definition?
I would temporarily rename the new class with some other name, then add a SomeClass member to it, then right-click and choose "Go to Definition", which should take you to the other definition.
So, change:
namespace My.SuperAwesome.Namespace
{
class SomeClass
{
}
}
To:
namespace My.SuperAwesome.Namespace
{
class NotSomeClass
{
SomeClass foo;
}
}
And go to definition on SomeClass.
You can consider the Class view window which shows you a hierarchical view of your namespaces and their members.
If you double click some class, it will show you all the definitions and where they are.
First, this is not the same as the many highly upvoted questions on this exact topic unless I'm missing one of them. All of them point that the issue is I have a namespace with the same name as the class. This is not the case (but it was).
I started out creating a new console application called BatchResizer and put a couple of classes there, but then decided to move this into a class library, called BatchResizer.Components; I then renamed the original console application to BatchResizer.ConsoleRunner, changed all classes in that project to namespace BatchResizer.ConsoleRunner.[...], set the assembly name and default namespace to the same.
There is a class titled BatchResizer but there are no namespaces titled [...].BatchResizer in the project anymore, but when I do var batchResizer = new BatchResizer() I get the error that the namespace is used like a class. There are items named like BatchResizer.ConsoleRunner.[...] or BatchResizer.Components.[...], but nothing ending in BatchResizer.
I've tried "cleaning" and rebulding the project, deleting the .suo file, deleting the /bin folder of all projects in the solution, and I've went through every class in all related projects for namespace collisions.
BatchResizer is still a namespace name, though. If it's also the same name as a class, you'll have to be more explicit:
var batchResizer = new Components.BatchResizer();
You could also add a using statement within your namespace:
namespace BatchResizer.ConsoleRunner
{
using Components;
internal class Program
{
private static void Main(string[] args)
{
var batchResizer = new BatchResizer();
}
}
}
If you want to get a bit geeky, then the C# 5.0 spec has this to say:
9.2 Namespace declarations
...The qualified-identifier of a namespace-declaration may be a single identifier or a sequence of identifiers separated by “.” tokens. The latter form permits a program to define a nested namespace without lexically nesting several namespace declarations. For example,
namespace N1.N2
{
class A {}
class B {}
}
is semantically equivalent to
namespace N1
{
namespace N2
{
class A {}
class B {}
}
}
So even if, as you say, no class is declared in the namespace BatchResizer, BatchResizer is declared as a namespace.
First, this is not the same as the many highly upvoted questions on this exact topic unless I'm missing one of them. All of them point that the issue is I have a namespace with the same name as the class. This is not the case (but it was).
BatchResizer may not be a 'final' namespace, but it' still a namespace
Namespace : Foo.BatchResizer.Components
Foo.BatchResizer.ConsoleRunner
Class : Foo.BatchResizer
I'm organizing a library project and I have a central manager class named Scenegraph and a whole bunch of other classes that live in the Scenegraph namespace.
What I'd really like is for the scenegraph to be MyLib.Scenegraph and the other classes to be MyLib.Scenegraph.*, but it seems the only way to do that would be to make all the other classes inner classes of Scenegraph in the Scenegraph.cs file and that's just too unwieldy.
Instead, I've organized it as Mylib.Scenegraph.Scenegraph and MyLib.Scenegraph.*, which sort of works but I find Visual Studio gets confused under some conditions as to whether I am referring to the class or the namespace.
Is there a good way to organize this package so it's convenient for users without glomming all my code together in an unmaintainable mess?
I don't recommend you to name a class like its namespace, see this article.
The Framework Design Guidelines say in section 3.4 “do not use the
same name for a namespace and a type in that namespace”. That is:
namespace MyContainers.List
{
public class List { … }
}
Why is this badness? Oh, let me count the ways.
You can get yourself into situations where you think you are referring
to one thing but in fact are referring to something else. Suppose you
end up in this unfortunate situation: you are writing Blah.DLL and
importing Foo.DLL and Bar.DLL, which, unfortunately, both have a type
called Foo:
// Foo.DLL:
namespace Foo { public class Foo { } }
// Bar.DLL:
namespace Bar { public class Foo { } }
// Blah.DLL:
namespace Blah
{
using Foo;
using Bar;
class C { Foo foo; }
}
The compiler gives an error. “Foo” is ambiguous between Foo.Foo and
Bar.Foo. Bummer. I guess I’ll fix that by fully qualifying the name:
class C { Foo.Foo foo; }
This now gives the ambiguity error “Foo in
Foo.Foo is ambiguous between Foo.Foo and Bar.Foo”. We still don’t know
what the first Foo refers to, and until we can figure that out, we
don’t even bother to try to figure out what the second one refers to.
Giving the same name to the namespace and the class can confuse the compiler as others have said.
How to name it then?
If the namespace has multiple classes then find a name that defines all those classes.
If the namespace has just one class (and hence the temptation to give it the same name) name the namespace ClassNameNS. This is how Microsoft names their namespaces at least.
Even though I agree with other answers in that you should not name your class the same as your namespace there are times in which you cannot comply with such requirements.
In my case for example I was not the person making such a decision therefore I needed to find a way to make it work.
So for those who cannot change namespace name nor class name here is a way in which you can make your code work.
// Foo.DLL:
namespace Foo { public class Foo { } }
// Bar.DLL:
namespace Bar { public class Foo { } }
// Blah.DLL:
namespace Blah
{
using FooNSAlias = Foo;//alias
using BarNSAlias = Bar;//alias
class C { FooNSAlias.Foo foo; }//use alias to fully qualify class name
}
Basically I created namespace "aliases" and that allowed me to fully qualify the class and the Visual Studio "confusion" went away.
NOTE:
You should avoid this naming conflict if it is under your control to do so.
You should only use the mentioned technique when you are not in control of the classes and namespaces in question.
I would suggest that you follow the advice I got on microsoft.public.dotnet.languages.csharp to use MyLib.ScenegraphUtil.Scenegraph and MyLib.ScenegraphUtil.*.
As others have said, it's a good practice to avoid naming a class the same as its namespace.
Here are some additional naming suggestions from an answer by svick to a related question "Same class and namespace name" on the Software Engineering Stack Exchange:
You're right that you shouldn't name the namespace the same as a type
it contains. I think there are several approaches you can use:
Pluralize: Model.DataSources.DataSource
This works especially well if the primary purpose of the namespace is
to contain types that inherit from the same base type or implement the
same interface.
Shorten: Model.QueryStorage
If a namespace contains only a small number of types, maybe you don't
need that namespace at all.
Make enterprisey: Model.ProjectSystem.Project
This can work especially for features that are important part of your
product, so they deserve their own name.
It happens when it's the main class of the namespace. So it's one motivation to put the namespace in a library, then the issue goes away if you add 'Lib' to the namespace name...
namespace SocketLib
{
class Socket
{
CA1724: Type Names Should Not Match Namespaces ...
Basically, if you follow Code Analysis for proper coding this rule says to not do what you are trying to do. Code Analysis is very useful in helping you find potential issues.
Old post, but here I go with another idea that may help someone:
"...but it seems the only way to do that would be to make all the other classes inner classes of Scenegraph in the Scenegraph.cs file and that's just too unwieldy."
This is really the better implementation for a bunch of scenarios. But, I do agree that having all that code on the same .cs file is annoying (to say the least).
You could solve it by making the base class a "partial class" and then, go on creating the inner classes on their own files (just remember that they'll have to declare the base class complement and then go on with the specific inner class for that file).
Something like...
Scenegraph.cs:
namespace MyLib
{
public partial class Scenegraph
{
//Scenegraph specific implementations
}
}
DependentClass.cs:
namespace MyLib
{
public partial class Scenegraph
{
public class DependentClass
{
//DependentClass specific implementations
}
}
}
I do think that this is the closer that you can get to having the clean implementation of inner classes while not having to clutter everything inside one huge and messy file.
Just Adding my 2 cents:
I had the following class:
namespace Foo {
public struct Bar {
}
public class Foo {
//no method or member named "Bar"
}
}
The client was written like this:
using Foo;
public class Blah {
public void GetFoo( out Foo.Bar[] barArray ) {
}
}
Forgiving the error GetFoo not returning the output instead of using the out parameter, the compiler could not resolve the data type Foo.Bar[] . It was returning the error: could not find type or namespace Foo.Bar .
It appears that when it tries to compile it resolved Foo as the class and did not find an embedded class Bar in the class Foo. It also could not find a namespace called Foo.Bar . It failed to look for a class Bar in the namespace Foo. The dots in a name space are NOT syntactic. The whole string is a token, not the words delimited by the dots.
This behaviour was exhibited by VS 2015 running .Net 4.6
I'm running into an issue where I can't make a reference to a class in a different namespace. I have 2 classes:
namespace Foo
{
public class Class1 { ... }
}
namespace My.App.Foo
{
public class Class2
{
public void SomeMethod()
{
var x = new Foo.Class1; // compile error!
}
}
}
The compile error is:
The type or namespace name 'Class1'
does not exist in the namespace
'My.App.Foo'
In this situation, I can't seem to get Visual Studio to recognize that "Foo.Class1" refers to the first class. If I mouse-over "Foo", it shows that its trying to resolve that to "My.App.Foo.Class1"
If I put the line:
using Foo;
at the top of the .cs file that contains Class2, then it also resolves that to "My.App.Foo".
Is there some trick to referencing the right "Foo" namespace without just renaming the namespaces so they don't conflict? Both of these namespaces are in the same assembly.
You can use global:: to globally qualify a namespace: global::Foo.Class1 should work,.
You could also alias global::Foo to make things easier. At the top of your source file, below your using statements, add:
using AliasClass1=global::Foo.Class1;
Now you can use:
AliasClass1 c = new AliasClass1();
// and so on.
Of course, you can use a better name than AliasClass :-)
var x = new global::Foo.Class1();
In addition to LBushkin's answer, you might be interested in these articles by Eric Lippert :
Do not name a class the same as its namespace, Part One
Do not name a class the same as its namespace, Part Two
Do not name a class the same as its namespace, Part Three
Do not name a class the same as its namespace, Part Four
They are not directly related to your problem, but they give an interesting insight on naming strategies