mit F7 erstellst du alle Projekte in der Solution.

Zum ersten:
Lagere die Gemeinsamen Dinge in ein neues Projekt (in der selben Projektmappe) aus. Dazu klickst Du mit der rechten Maustaste auf die Projektmappe, dann Hinzufügen -> Neues Projekt -> Klassenbibliothek.
Dann fügst Du beim Client und beim Server einen Verweis auf die gemeinsame Bibliothek hinzu.
Das könnte beispielsweise so aussehen:


Zum zweiten:
Gleichzeitig debuggen ist möglich, wenn Du die Projektmappe in 2 VisualStudio-Instanzen gleichzeitig öffnest. Pass aber beim Ändern von Dingen auf, dass Du nicht durcheinander kommst.

ein Server und ein Client in derselben Solution?
Normal sind das aber doch 2 verschiedene Programme.
Und eine Solution kann nur ein Programm generieren/erstellen.

Ähnliches hab ich mit VersuchsChat mit leistungsfähigem Server gemacht, der Trick besteht aber darin, dass das Programm sowohl server als auch Client sein kann.

Jdfs ein Visualstudio kann in einer Solution nur ein Programm debuggen.

Naja, man kann ja beide vom VS direkt aus starten - aus meiner Sicht macht das so wie Niko das macht Sinn.

schockerjo schrieb:

Wenn "Core" (das Namespace, das die Programme sich teilen) als FormsAnwendung oder Konsolenanwendung deklariere, wird eine exe mitgeliefert.

Deklarier ihn als "Klassenbibliothek".

In der Dll sind von beiden Programmen gemeinsam genutzte Programm-Teile drin - wie sollen die Programme funktionieren, wenn die Dll weg ist?

Du kannst DLL's mit ILMerge einkompilieren lassen.
Dafür gibts auf Codeplex eine GUI-Version: ilmergegui.codeplex.com

@ErfinderDesRades:

ein Server und ein Client in derselben Solution?
Normal sind das aber doch 2 verschiedene Programme.
Und eine Solution kann nur ein Programm generieren/erstellen.

Bin mir nicht ganz sicher, was Du meinst, aber man kann auch mehrere Projekte in eine Solution packen, die .exe-Dateien erstellen (sind ja auch nur Assemblies). Nur gleichzeitig debuggen geht in einer VS-Instanz halt nicht.
HALT STOP! Ich nehme alles zurück!

@Thread
Rechtsklick auf die Projektmappe (nicht das Projekt, sondern die Projektmappe) -> Startprojekte festlegen -> "Mehrere Startprojekte" auswählen -> für die einzelnen Projekte die passenden Aktionen auswählen.
Ha! Geht doch

Und wegen den Dlls: Man kann die, wie erwähnt wurde, zwar einkompilieren, ist aber im Normalfall nicht nötig. Man hat halt den Ordner mit mehreren Dateien drin und doppelklickt einfach auf die Exe. Wem das zu viel ist, kann sich eine Verknüpfung auf dem Desktop auf die Exe-Datei anlegen, und den Ordner irgendwo hin verschieben, wo er nicht stört... ein Setup würde das auch machen können, ist aber meistens nicht nötig.

Edit:
@schockerjo
Ich glaube, Du hast da was falsch verstanden.
Die beiden Programme brauchen die Dlls, damit sie die selben Klassen verwenden können.

automatisch mit Visual Studio

geht nur, dass die benötigten Dlls in den bin\Release-Ordner kopiert werden. Wenn Du z.B. alle Dateien aus Server\bin\Release kopierst und weiter gibst, hast Du alle Dateien, die der Server benötigt. Das wären dann die Server.exe und die Core.dll.
Und in Client\bin\Release liegt die Client.exe, und halt eben auch die Core.dll, weil die Core.dll wird von beiden benötigt.

Ich glaube schon. So wie Code-Dateien, die bei beiden Projekten kompiliert werden. So, als würde man in beiden Projekten den gleichen Code kompilieren.
Das würde unter Umständen zwar funktionieren, aber das ist nicht zu empfehlen. Denn ein ServerNamespace.CommonType ist nicht das selbe wie ein ClientNamespace.CommonType. Die Typen heißen zwar gleich und haben auch die gleichen Member, aber der eine Typ ist eben in der Server-Assemby, und der andere in der Client-Assembly deklariert.
Den Unterschied sieht man, wenn man GetType(ServerNamespace.CommonType).AssemblyQualifiedName ansieht.

Du könntest (wie in Post 4 gezeigt) deinen Code in die Projekte Client, Server und Common (oder Core) aufteilen, Common jedoch nicht selbstständig kompilieren und somit benötigte DLLs erzeugen, sondern stattdessen die Codefiles aus Common per Link in die Server und Client Projekte hinzufügen. Dazu verwendest du die folgenen Schritte:
Rechtsklick auf ein Projekt (hier Client oder Server) -> [Hinzufügen] -> [Vorhandenes Element...] -> Auswählen der Datei(en)
Nun drückst du NICHT direkt auf Enter oder auf [Hinzufügen], sondern auf den kleinen Pfeil daneben. Nun erscheint eine Schaltfläche, wo du unter anderem die Auswahl [Als Link hinzufügen] findest. Verwendest du diese, um Dateien zu Projekten hinzuzufügen, werden Änderungen in jeder der Verlinkungen sowie in der Originaldatei gespeichert und du musst nur eine Datei modifizieren.
Bevor ich hier jetzt einen Shitstorm lostrete, ich nenne nur die Lösung für das genannte Problem und sage nicht, dass dieses VS-Werkzeug die beste Wahl für diese Softwareentwicklungssituation ist. In vielen (nicht allen) Fällen wird eine DLL, die sich die beiden Projekte teilen, die bessere Lösung sein, dennoch hat, denke ich, auch diese Lösung ihre Daseinsberechtigung.
Bspw. muss man bei dieser Lösung beachten, dass die Klassen letztendlich nicht die selben Klassen sein werden (wie Niko bereits erwähnte), da sie in unterschiedlichen Assemblys existieren. Dies sollte jedoch von der Funktionalität häufig keine Unterschiede machen und mit den Namespaces hat das auch nichts zu tun. Die Klasse(n) können auch gut und gerne den gleichen (Common-)Namespace haben, da Assemblys problemlos verschiedene Namespaces beinhalten können.

Achja, als Student habe ich die Möglichkeit den vollen Umfang der Visual Studio Produkte zu nutzen, ich weiß leider nicht, ob die Express Versionen das oben erläuterte Feature ebenfalls beinhalten

Express Versionen

Scheint auch in der Express-Version (zumindest Visual Basic 2010) zu funktionieren.
Ich denke, das ist eher ein "Wenn mans mal wirklich braucht, hat mans"-Feature.

eine DLL, die sich die beiden Projekte teilen, die bessere Lösung sein

Richtig.

ErfinderDesRades schrieb:

ein Server und ein Client in derselben Solution?
Normal sind das aber doch 2 verschiedene Programme.
Und eine Solution kann nur ein Programm generieren/erstellen.

ErfinderDesRades schrieb:

Jdfs ein Visualstudio kann in einer Solution nur ein Programm debuggen.

Beides stimmt nicht. Du kannst in einer Solution so viele ausführbare Programme haben wie du willst. Wird auch häufig gemacht. Beispiel: SharpDX hat in der Beispiel-Solution zig ausführbare Projekte. Auch Microsoft selbst verwendet dieses Feature von VS recht häufig. Hin und wieder sieht man auf Channel9 Videos wo z.B. 5 Projekte für 5 verschiedene Platformen drinnen sind (alle ausführbar). Zumal in .NET ja ein ausführbares Projekt auch so gut wie das selbe wie eine Klassenbibliothek ist (bis auf den Einstiegspunkt). Geht jedoch auch mit den anderen Sprachen wie z.B. mit nativem C++ (kannste ebenfalls so viele ausführbare Projekte in eine Solution packen).

Ebenso kann man natürlich zwei Projekte gleichzeitig debuggen. Entweder startet man diese nacheinander mit angehängtem Debugger oder legt gleich in den Solution-Einstellungen mehrere Startprojekte fest (wobei man auswählen kann ob diese jeweils mit einem Debugger oder ohne Debugger gestartet werden sollen).

Hmm - Hab ich jdfs. noch nicht rausgefunden, wie das gehen soll