am new for c# socket programming so if you can please help me how can I fix this errors

In addition to Solution 1:

Here is the thing: in .NET and CLR, the main functional block and the center of its modular conception is assembly, not "DLL" or "EXE". Those PE (executable) files are nothing but modules. Visual Studio directly supports creation of only the assemblies which are made of only one module, but it's possible to create an assembly with more that one module; then one module is only main; it has the assembly manifest in it. Even for one-module assemblies, the concept of module is not redundant, the file ("EXE", "DLL") is always the module, not assembly, and you can always calculate the module from reflection, and thus get, for example, the file name.

Those modules should be not confused with referenced assemblies. Many assemblies reference other assemblies they depend on. Naturally, any assembly can be referenced by more than one assembly. If the assembly is referenced, all of its modules should present in the system, so, recurrently, the same goes for the assemblies it references in turn.

Now, we are coming to the main idea: the concept of "DLL" and "EXE" are totally irrelevant to .NET and CLR. They are nothing but naming conventions for the file names. By default, if you specify "class library" as the output type, ".DLL" is created, ".EXE" in all other cases. When an assembly is created, it can be referenced by other assemblies, even if it is ".EXE". Not a library? Does not matter. There are even cases when referencing the ".EXE" makes practical sense. (Let me skip this topic.) So, how "class library" assemblies are different form other output types? They can be successfully compiled without the method called entry point, but non-libraries are required to have exactly one: some static Main function of some class. If you have two such functions, you have to chose one, so the runtime system would "know" what to call. Please see: http://en.wikipedia.org/wiki/Entry_point#C.23[^].

The library assemblies may or may not have such function, of have more than one, or more. This is the only difference between "DLL" and "EXE". Moreover, you can create your own runtime system and the type of host where some "DLLs" would play the role of "application".

Now, as Solution 1 explained to you, only application assembly can be started, because the runtime system "knows" how to start them: by calling Main. As to the "startup project", this is just the artifact of Visual Studio (or other IDE), as well of the concept of "project" itself. There are no "projects" during runtime. This startup project is needed by only one trivial reason: because there is one comment "Start Debugging" menu item which is supposed to work ignoring the selection in Solution Explorer. That's why there is on additional "selected" item. And, naturally, Visual Studio should "know" how to "run" it, so a library is not suitable. This is as simple as that.

By the way, I want to use the occasion to shed some light on "mysterious" "Console Application" output type. Many mistakenly think that it means "not windows application". Wrong. This "classification" of Visual Studio is utterly misleading. This item simply means "show console". In other words, if you develop a window application, it won't show console, but if you then change the output type to "console application", it will show console but will remain a window application, with all the UI you developed. Don't let VS to confuse yourself. :-)

—SA