We Keep Coding

Import class from another folder

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;

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.

C# namespaces: how to follow standards without causing annoying conflicts?

I'm working on a C# library (let's just call it "Foo" for the sake of this question). It has some needs very similar to standard .NET needs: for example, it provides some drawing services, and some conversion services.
For the sake of familiarity and users of the library being able to guess what things are called, I'd like to follow the .NET standard, and name these parts of the library Foo.Drawing and Foo.Convert (and so on). But I'm finding that in actual use, this causes pain. People almost always have "using System;" at the top of each file, and when using this library, they want to have "using Foo;" as well. But now they have two Drawing and two Convert modules, and hilarity ensues.
For example, now instead of just using Drawing.Color for a parameter or variable type, you have to explicitly spell out System.Drawing.Color, or the compiler complains that Foo.Drawing doesn't have a Color type. Similarly, you want to use a standard Convert.ToInt32, you have to say System.Convert.ToInt32, even though you're already using System, because otherwise it finds Foo.Convert and fails to find ToInt32.
I understand why all this is as it is, but I'm still new to the C# community, so I don't know which is the most standard solution:
Leave it this way, and expect users to use fully-qualified names where necessary?
Rename the conflicting modules to something else (maybe Foo.Graphics instead of Foo.Drawing, and Foo.Conversion instead of Foo.Convert)?
Use some prefix on the standard names (Foo.FDrawing and Foo.FConvert)?
Something else?
Any advice from you more experienced C# gurus will be appreciated!

You can use namespace aliasing :
using System;
using FConvert = Foo.Convert;
public class Bar
{
public void Test()
{
var a = Convert.ToInt32("1");
var b = FConvert.ToInt32("1");
}
}

One of the main usage of namespaces is to avoid name clashing.
It means that namespaces allow developers to create types with identical names, as long as the belong to different namespaces.
A library usually have at least a root namespace, and possibly nested namespaces that logically groups the related types.
Name your types as you wish, as long as the names are meaningful and represent what the type really are. A client of your library expects a type named Animal to represent an Animal, not something else. The same applies for naming namespaces.
However, avoid at all cost the names from System, since it will be really annoying for your library clients (as you described) to deal with conflicting names all over the place.
A common way to deal with conflicting namesapces inside a class is to use namespace aliasing:
using FooConvert = Foo.Convert;
using BarConvert = Bar.Convert;

C# Namespace Alias qualifier (::) vs Dereferencing Operator (.)

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