We Keep Coding

How to deal with invisible c# namespaces in Unity editor?

The unity documentation recommend to use namespaces to organize your code, avoid extended class name, and make more maintainable code.
ControlerCameraAction becomes Controleurs.Cameras.Action and CameraAction becomes Cameras.Action.
However in Unity editor you can't see your namespaces, only the last class name, and this can be confusing since some class have now same name.
Editor shows now Action and Action
So how to use namespaces in Unity?
Am I doing something wrong?

So how to use namespaces in Unity ?
Like you did, basically. Namespaces are used in code, not in the editor. The main problem of Unity is the way that scripts are treated. Scripts get compiled internally into debuggable IL-Code.
But in the editor itself, they are always named by their filenames, which are forced to be the same as the class name.
This is the reason you don't see your whole type-name (namespace + classname), but always the classname alone.
Am i doing something wrong ?
No, you aren't. As far as I remember, there is no way to display the classname instead of the filename in the editor, since the displayed data is determined by the meta-files that Unity generates.
So tl;dr:
You are doing it right and there is no way to display the namespaces in the Editor.
I'd suggest you should sort your scripts into folders and use the AddComponentMenu-Attribute to organize your code physically according to your namespaces. This is the same pattern that is used by Microsoft.

Easy way is to think in namespace how file folder. You assign your desired name avoiding similar name to systems and unity namespace. Each namespace inside another namespace is similar to navigate inside a folder inside another folder.
Ussually this start with your company name or your plugin name:
namespace mycompany_name
{
namespace myplugin_name
{
}
}
or
namespace myplugin_name
{
//part name i.e. Networking, Utils, Database or similar ramification
namespace myplugin_part_name
{
}
}
Later you reference to it in another script with "using":
using mycompany_name.myplugin_name

The unity documentation recommend to use namespaces to organize your
code, avoid extended class name, and make more maintainable code.
Yes !
ControlerCameraAction becomes Controleurs.Cameras.Action and
CameraAction becomes Cameras.Action.
Yes, and no.
The idea behind namespaces is organization not just simple use this feature called namespaces. And that organization should follow a logic. If every class has a different namespace then you will have to import as many namespaces as classes that you will use in your code.
You can think in terms of 'modules' or maybe see if a layered architecture can be useful for you.
If you have ControllerCameraAction and CameraAction, you can a.- use the namespace Cameras for both (then you will have Cameras.CameraAction and Cameras.ControllerCameraAction) , b.- if you have a layered architecture (like MVP, MVVM, or some more DomainDesign Driven, etc.) you can have namespaces using the layer name and the module. (then you will have something like Presentation.Cameras.ControllerCameraAction, Domain.Cameras.CameraAction and this can help you to follow an Onion architecture).
The syntax for namespaces are like this:
namespace Domain.Cameras
{
public class CameraAction
{
}
}
And you use them with using directive
using Domain.Cameras;
namespace Presentation.Cameras
{
public class ControllerCameraAction
{
private CameraAction cameraAction;
...
}
}
More about namespaces here!
By default all classes that don't have an explicit namespace belong to global namespace, so even when you are not writing any namespace you are using one.
Unity will not make any difference between namespaces, this is more a c# characteristic. And it helps with organization, separation of concerns principle, and avoiding name conflicts too, but in the last instance, your class names should still be representative and clear enough to understand what that class does. If you see Camera.cs and Camera.cs it's really hard to see what class does what. If you open those files and see the namespace/code/folder where they are that will help, but the idea is save those extra seconds/cognitive load and just be more explicit with your names.
As a complement here you can see another interesting discussion about namespaces use.

The type or namespace name "..." could not be found

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.

What is the difference between namespace dot namespace and nested namespace?

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.

C# Using Classes in Project

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
{
.........
}

C#: why can I not create a system namespace?

I remember few weeks ago when I reorgnized our code and created some namespaces in our project I got error and the system did not allow me to create a companyName.projectName.System namespace, I had to change it to companyName.projectName.Systeminfo. I don't know why. I know there is a System namespace but it is not companyName.projectName.System. I think A.B.C namespace should be different with A.A.C namespace. Right?
EDIT
The error I got is like the this:
Error 7 The type or namespace name 'Windows' does not exist in the namespace 'MyCompany.SystemSoftware.System' (are you missing an assembly reference?) C:\workspace\SystemSoftware\SystemSoftware\obj\Release\src\startup\App.g.cs 39 39 SystemSoftware

You're experiencing a namespace clash.
If you name the last part of your namespace System, then the compiler will have a hard time determining if you're referring to the (Microsoft) System namespace or an inner System namespace at your current level (or even an System class or property or ...).
You'll experience the same problem with class names and namespace parts. You can't create a class called System for the same reasons.
Unless you feel like specifying full namespaces for all of your instances.

The code below compiles and runs, so I think you'll need to give us a bit more detail as there's no reason you can't create a namespace such as companyName.projectName.System as far as I'm aware.
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
var x = new ConsoleApplication1.Project.System.Something();
}
}
}
namespace ConsoleApplication1.Project.System
{
public class Something
{
}
}

It's probably because you can use relative namespaces in .NET.
if you have an object in the namespace A.B.C, then when you are coding in the namespace A.B, you can refer to that object as just C.ObjectName, instead of A.B.C.ObjectName. Therefore, if you were at the companyName.projectName level, System would be abiguous, unelss you were to start using namespace aliases.
However, I found the best approach is to avoid the thing that is causing the confusion in the first place, and change your System namespace to something else, and it all ceases to be a continuing problem.

C# can only get confused. Please read the following topic on Eric Lippert's blog. I know that he speaks about classes and namespaces, but the same or other related behaviour may occur.

Eric Lippert just posted on a closely related issue. http://blogs.msdn.com/ericlippert/archive/2010/03/09/do-not-name-a-class-the-same-as-its-namespace-part-one.aspx
By creating x.y.System for code in the x.y namespaces it becomes difficult to determine if you are referring to x.y.System.Foo or System.Foo.
I would come up with a different name for the sake of clarity.