Is there any difference between:
namespace Outer.Inner
{
}
And
namespace Outer
{
namespace Inner
{
}
}
in C#?
Assuming you don't put any other declarations or using directives in the Outer namespace, there's no difference at all.
Given that you would very very rarely declare members in multiple namespaces within a single file, I'd suggest using the first form - aside from anything else it saves a level of indentation. Note that "brace at the start of a new line" is a more conventional bracing style for C# though:
namespace Outer.Inner
{
...
}
No difference whatsoever, those are the same thing, however the first one is more common.
No, but the first variant is the most used in c# code.
The second variant is what you'd have to write in C++ and I'm not sure I ever saw it in real c# code yet.
They both are the same as noted by other answers and per documentation here.
Also the fact the one namespace is defined inside another doesn't really mean that it has any special relationship with the parent or that it brings any particular features in relation with parent or that it depends on parent namespace. There is no relationship other than it's just defined inside parent (in context of using statement to bring them in).
As such, it is important to note that if you include the parent namespace, it doesn't meant the child names are now accessible. See this answer which explains this.
So despite the fact they are nested, for all practically purposes, each namespace is its own independent thing, no matter if its the top most parent or a child. You will always need to use fully qualified name of the nested namespace if you want to include it.
As such the dot(.) almost becomes part of the namespace much like you can have a gmail id as first.last#gmail.com
So why nested?
It really is just to logically place them as if they are in a hierarchy for benefit of organizing them but you can think of the dot in the name as part of the namespace (for all practical uses).
for example you can define this:
namespace Outer.Inner
{
class MyClass{}
}
But if you wanted, you can rename the above to the following for all practical purposes:
namespace Solar
{
class MyClass{}
}
In both cases if you want to use MyClass, you will need to include fully qualified name of the namespace where the class is defined which is:
using Outer.Inner;
or
using Solar;
This can best be understood and summarized in looking at C# library namespaces.
using System;
using System.Threading;
using System.Threading.Tasks;
So although, the above three lines contain nested namespaces, each line really is fully qualified name to a unique namespace (as if the dot is part of the namespace) and that should be useful to know in terms of the differences and usage.
Related
begginers question about C#.
In every program I have to include several namespaces, like:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
Why do I have to include:
using System.Collections.Generic;
using System.Linq;
using System.Text;
... since they are included with first one:
using System;
Thank you in advance!
Because nested namespaces are not included with parent one. See using directive documentation for details
A using directive does not give you access to any namespaces that are nested in the namespace you specify.
System and System.IO namespaces are different.
You can treat "subnamespace" as parent-child relationship in the object model. If you have access to the "Car" object does not mean that you have access to car's wheels.
System is a huge namespace that contains hundreds of nested namespace and thousands of classes. You should specify all nested namespaces separately to state what part of the module are you interested in.
Imagine these namespaces with these classes (the last name is a class):
A.B.Class1
A.Class2
Now you have the following:
using A - allows you to refer to Class2 directly... but not to Class1.
using A.B - allows you to refer to Class1 directly but not to Class2.
If you want to refer to both classes directly in your code, you need both usings.
System and System.Text are two different namespaces. That System.Text seems to be a part of System is the semantics we as programmer put into it. There's no such thing as a nested namespace from a platform view;
But even if that was not the case what should happen if you had
namespace MySystem{
namespace Foo{
class Bar {...}
}
class Bar{...}
}
using MySystem;
class MyClass{
private Bar _myBar; //Which one is it MySystem.Foo.Bar or MySystem.Bar?
}
Since you're beginner let me clarify one thing namespace in C# and package in Java are different things. no need to merge them.
Not all classes in .net is inside one big container.Doing so increases the chance of class name collision and it doesn't look good in the first place.Namespaces are containers that try to keep your library clean and make more sense.Having a FTP class and String class together under one container does not logically make any sense.They do two different things and they should be kept in separate containers.
Also a namespace can be nested.Sometime A namespace can all but have just another namespace,without any class.so to access a class you need to qualify the full namespace before you can use it.
In your case you use different classes ,which are on different containers.So if you need them you need to qualify them with their namespace.
Just an added example to make you understand clearly.
A child Namespace cant be accessed by calling parent namespaces
Namespace Main //only code and classes are accessible
{
//code for Main Namespace
Namespace subMain //only code and classes are accessible
{
//code for subMain
Namespace verySubMain //only code and classes are accessible
{
//code for verySubMain
}
Namespace otherVerySubMain //only code and classes are accessible
{
//code for otherVerySubMain
}
}
}
If you wanted access to a class in System.Text without the using statement, you would have to Text."Name of class/function" every time you wished to use it.
This way you can just call "name of class/function".
Not sure if you are a beginner, but that's the simplest way I can describe put it.
I'm new and I don't know other way to explain so I posted my screenshot of project! Please help me to fix these errors... SCREENSHOT
You seem to be having a lot of problems with references and namespaces use.
First of all, you do not have a Card class defined. You only have a CardModel. Replace Card for CardModel and you will be good to go. Also, it seems you do not have a namespace declared on your class. Declare a namespace so you can use other classes in the same namespace (tipically the project name).
Second, if you are trying to use clases in another folder, you probably have to add the reference with the using keyword.
You're missing probably several using directives. Every class you write should be inside a 'namespace' You declare it after your using directives but before you start writing your classes, like this:
namespace WebShop.CardModel {
public class CardModel {
public string InsertCard(Card card){
And when you are working in the cardModel, unless Card is defined in the same namespace, you need:
using WebShop.Card;
Or whatever namespace you put Card in, that's what is throwing probably 99% of your errors, it is definitely the cause of all but one of the ones in the errors we can see in your screenshot.
I have the following two files:
IGlobalApiProvider.cs
using System.Collections.Generic;
using Vert.Slack;
namespace Vert.Interfaces
{
public interface IGlobalApiProvider
{
List<Im> ImList();
}
}
And the corresponding implementation: SlackApi.cs
using System.Collections.Generic;
using Vert.Interfaces;
namespace Vert.Slack
{
public class SlackApi : IGlobalApiProvider
{
public List<Im> ImList()
{
...
}
}
}
Now, Intellisense is telling me that when I use IM in IGlobalApiProvider it's resolving to Im, which is defined in a file named RtmStart.cs which has no namespace declaration. When I use IM in SlackApi.cs, it's resolving to Vert.Slack.Im which is defined in the Vert.Slack namespace in a file named Im.cs. The weird behavior alerted me to the redundant definition, so I removed it and things are working fine.
However, I'm confused about why Visual Studio behaved differently in these two ways. I can tell something was scanning for the class names in a different pattern in the two situations. I can also tell that being used in the same namespace vs being used in a class that uses the namespace seems to be the trigger. What I don't know is what mechanism controls the logic behind this behavior.
Can anyone shed light on this?
Everything you see is contained in Vert.dll, which consists of one project, Vert.csproj
Link to the four files mentioned in this post as they existed at the time of writing.
This has to do with the difference between the global and Vert.Slack namespaces.
The compiler looks for the most explicit namespace with the proper class defined.
In this example, when the compiler looks for the definition of Im in IGlobalInterfaceProvider.cs, there is no namespace defined (or used) in this file that contains the class, but Im is also defined in this file - which is declared in the global namespace.
When the compiler looks for the definition of Im in SlackApi.cs, Im is found in the explicit Vert.Slack namespace, and utilizes that class.
The answer here is a similar topic and may provide more insight.
This may be related to the fact that your namespaces are in the wrong place ;-)
http://www.stylecop.com/docs/SA1200.html
This answer here gives a good explanation: Should 'using' statements be inside or outside the namespace?
I have organised my project with separate folders for groups of classes, but now in order to get to any method I have to reference the whole path like:
Classes.Users.UsersClass.Get();
Classes.Database.ConnectionClass.Test();
if (!Classes.Database.UsersMethods.Authenticate())
{
Classes.Users.UsersClass.LoginFailed();
}
As you can see, this is going to get messy after a while, so is there a way I can just call the class directly?
/Edit
This is the fixed up version:
Users.GetWindowsUser();
Connection.Test();
if (!UserMethods.Authenticate())
{
Users.LoginFailed();
}
You can add a using directives at the top of your C# file:
using Classes.Users;
using Classes.Database;
This would then let you type:
UserClass.Get();
ConnectionClass.Test();
That being said, I would strongly recommend not using "Class" as a suffix on every class, and also recommend not using a namespace named "Classes". Most things in C# are classes - there is no need to suffix every class with this in terms of naming.
For details, please refer to the Namespace Naming and Class Naming guidelines on MSDN.
Add the appropriate using statement to the top of your file. E.g. using Classes.Database;
Also, in VS 2010 if you just type the name of the class without the namespace (e.g. ConnectionClass) then hit ctrl+. it will give you the option to automatically add the appropriate using statement.
you can simply put using directives on the top of the file, or
if you don't want the classes to be in separated namespaces go to the class file and change the namespace to project original namesapce
namespace myProject.SubFolder
{
.......
}
will be
namespace myProject
{
.........
}
Quick and simple question. I kind of understand what the Namespace Alias qualifier does, it's for accessing members in a namespace, however so does the dereferencing operator. I am really baffled as to the difference in this situation, why you would use one over the other, or how they each accomplish the same thing.
using colAlias = System.Collections;
namespace myns
{
class TestApp
{
static void Main()
{
colAlias.Hashtable test = new colAlias.Hashtable();
colAlias::Hashtable test1 = new colAlias::Hashtable();
}
}
}
This is a corner case :: (like the # prefix) is there to deal with the fairly rare occurrences where a name conflicts between namespaces, classes and keywords.
:: only works for namespaces (and namespace aliases), while .. works for both namespaces and subclasses. Most places where you'd need it you'd be better off using a different name instead, but that isn't always an option.
global:: is a special case that's most often seen in auto-generated code - it resets the referenced namespace to the root.
For instance, suppose you auto-generate some code (maybe for a forms app, EF, or similar) and your app uses the namespace YourCompany.Application. Now one of your customers (using your auto-generation) decides to add their own namespace in their app TheirCompany.YourCompany.Application. Now all your auto code fails because when it compiles .Net doesn't know whether to use your namespace or theirs.
To fix this generate code with global::YourCompany.Application, then those that use your auto-generator can use whatever namespace they like and not conflict.
I think Microsoft added global:: because they expected some .Net customers to add namespaces like System.
You said:
Namespace Alias qualifier does, it's for accessing members in a namespace, however so does the dereferencing operator.
Well, no. The . operator is used to access any member, including functions. You cannot do Console::WriteLine();
:: is only for resolving namespaces, either from a namespace alias like this:
using colAlias = System.Collections;
...
...
colAlias::Hashtable test = new colAlias::Hashtable();
OR from global.
global::System.Console.WriteLine(..);
You cannot do :
System.Collections::ArrayList a = new System.Collections.ArrayList();
BUT, if you have an alias the . operator also works, so in your case, there is no difference.
There's an MSDN page explaining how this works.
Basically, in your situation they will achieve the same thing and for code readability it's preferred to use a single ..
I wouldn't use the :: operator on anything but the global namespace, and even then there are more than enough ways to work around it.
edit: More information what the operator does is explained at the :: Operator (C# Reference) article.
The general idea of a namespace qualifier is to allow you reference the namespace even if the name has been used elsewhere. If you declared a class named "colAlias" then colAlias.Hashtable would reference the class but colAlias::Hashtable would reference the namespace'd value.
This is a fairly narrow use-case and global:: is the only typical use case I have seen for this operator (When trying to ensure no conflicts can occur when creating generated code to be compiled in an unknown application).
The namespace alias qualifier (::) helps you to access namespace methods without causing errors if you have CONFLICTING namespaces using the same naming convention.
For example as explained here in msdn
http://msdn.microsoft.com/en-us/library/c3ay4x3d(v=vs.80).aspx