Ohne static geht einfach nicht.
Es ist weder klar, wann die der Speicher initialisert wird noch wann der Garbage Collector die Funktion einsammeln wuerde.

Programmatisch koenntest Du Dein Zertifikat auch an die richtige Stelle kopieren - aber um eine Sicherheitsfrage kommst Du dabei dann auch nicht herum - ausserdem wirds wacklig, wenn das Zertifikat abgelaufen und aktualisiert werden muss.

Die Grundfrage ist, ob Du feste oder wechselnde IP-Adressen hast.
Fuer feste Adressen wirst Du im Regelfall so etwas wie stunnel benuzten.
Bei wechselnden Adressen brauchst Du so etwas wie dyndns, damit Du die gerade aktuelle Adresse herausfindest - so etwas wie stunnel solltest Du dann trotzdem benutzen.

Ich waere mit dem Zaehlen der Operationen sowieso sehr vorsichtig, denn es spielen auch Dinge wie Code-Optimierung und CPU Caches eine sehr gewichtige Rolle.
Die Latency-Tabelle (Latency Numbers Every Programmer Should Know) gibt Dir mal eine Idee, wie komplex das Thema ist.
Im Zweifel ist es immer besser, kleine Testprogramme zu schreiben und dann fuer die gleichen Testdaten die Laufzeit messen.

Ich bezweifle stark, dass mischen ueberhaupt funktioniert - Du hast an sich nur ein .NET Runtime, die verschiedene .NET Versionen unterstuetzt.
Zu einer Runtime gehoert nur eine Version von ngen - neue Runtime erfordert auch neues Bauen mit ngen.

Ich wuerde mal protobuf.net ausprobieren - bei mir war es ca. 6 mal schneller als Binary Serialization.
Es arbeitet auch mit Attributen - Attribute sind Reflection zur Compilezeit.

Du musst aber neben dem Service Namen noch andere Parameter (zumindest den Port) konfigurieren - ausserdem machst Du die Verwaltung und Upgrades deutlich muehsamer mit mehreren Instanzen mit eigenem Namen. Waere es nicht einfach, wenn Du innerhalb Deine Service einfach anders aufbaust, so dass es einen Service mit mehreren Listenern gibt?

Fuer die Distributionen wuerde ich Dir Math.Net empfehlen.
Im Iridium Paket findest Du verschiedenste Verteilungen.

Bekommst Du eine Exception?
Gibt es schon eine Instanz von WindowsFormsApplication.exe?
Unter welchem ser laeuft der Server und unter welchem User soll die WindowsFormsApplication.exe laufen?

Status sollte am besten ein enum werden, dass Du dann mit Switch auswerten kannst.
So bekommst Du dann sprechenden Code - oder willst Du jedesmal ueberlegen, was Zustand 007 logisch bedeutet?

GetSystemWebProxy-Methode ist User bezogen - hast Du es mal mit einem Hardcode oder einem Konfigurationsparameter probiert?

Hat jetzt nix mit C# zu tun...
Am saubersten ist es, wenn Du eine Verbindung direkt ueber Deinen Default Router und fuer die 2. Verbindungen einen Proxy (z.b. Squid) benutzt.

In .NET 2.0 gibt es die Namensbereiche System.CodeDom and System.CodeDom.Compiler, die Du Dir anschauen solltest.
Unter dem Stichwort findest Du auch einige Treffer bei der Suche.

Sowas hier wuerde ich nicht bei jedem Senden neu machen:

 System.Net.Sockets.NetworkStream clientStream = TCPClient.GetStream();

Mach daraus doch eine privates Attribute, dass Du im Konstruktor initialisierst.

Bei externen Komponenten solltest Du Dich mit Mocking vertraut machen und auch ueberlegen, dass Du dann damit das Verhalten der externen Komponenten nachstellen kannst.
FakeItEasy ist da mein aktueller Favorit.

Du solltest mit Interfaces arbeiten und Deine Instanzen sollten ein Interface implementieren, nicht die konkrete Klasse, dann sollte das kein Problem sein...
Wenn eine Referenz zu dem Untertyp gehoert, dann kannst Du die Referenz nicht mehr anpassen...

Wenn es um GUIs/kleine Datenmengen geht, dann bist Du mit dem asynchronen Modell im jedenfall besser dran.
Bei grossen Mengen und Servern ist das synchrone Modell schneller, da der Overhead fuer den einzelnen Lesevorgang kleiner ist. Overhead ist vor allem das zusaetzliche Stateobjekt.

Pioneer, Du scheinst synchrones und asynchrones Programmieren zu vermischen.
Thread.Sleep() solltest Du aus dem Wortschatz verbannen.
Ein blockendes Receive ist immer ressourcenschonender und macht das gleiche.
Wenn Du Dich nicht an Monitor.Wait() und Monitor.Pulse() rantraust, würde ich mich den BlockingCollections arbeiten und Queues mit einem Element benutzen.
Der sauberere Weg wäre es sonst mit Delegates/Events zu arbeiten, wenn Daten ankommen.

Hast Du alle Methoden aus diesem Artikel implementiert - wahrscheinlich läuft Dein Dienst noch immer. Wenn eine exe sich beendet, werden immer automatisch die Sockets freigegeben.
Wenn Du es nicht sauber gemacht hast, kann es ein paar Sekunden dauern, aber im Zweifel räumt Windows selbst auf.

MS wird wohl VS Express 2012 anpassen, so dass Desktop auch unterstützt wird - siehe hier

Den Poll brauchst Du nur, wenn Du synchron arbeitest.
BeginReceive arbeitet asynchron implizit mit einem Thread aus dem Threadpool, der Deinen Code ausfuehrt, wenn Daten kommen.

Du solltest vor dem Receive mittels

connector.Client.Poll(SelectMode.SelectRead, timeout) 

pruefen, ob Daten anstehen. Ansonsten solltest Du nach dem timeout pruefen, ob der Service sich beenden soll oder nicht.
Doku kannst Du im Zweifel nochmals anschauen.

Wahrscheinlich musst Du in den Einstellungen den Energiesparmodus anpassen - mir ist vor kurzem auch so etwas aehnliches widerfahren...

MSBuild gehoert zum Plattform-SDK und das ist auch in der Zusammensetzung mit Windows 8 geaendert wird, da die Compiler jetzt eigene Komponenten geworden sind und somit keine vollstaendige Build-Umgebung mehr ist.
Siehe Windows Software Development Kit (SDK) for Windows 8 Release Preview.

Die Settings speichern solltest Du mit

ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None).Save();

speichern koennen.

Ich wuerde mir mal mit Fiddler genau anschauen, was gesendet wird, wenn Du die Webseite benutzt und was Deine Applikation sendet.
Das sollte Dir helfen, Dein Problem besser zu verstehen, da Du dann genau vergleichen kannst.

Serialisieren ist gut - wenn Du sauber arbeiten willst, dann sollte jede Schnittstelle eine eigene Klassenbibliothek/Dll werden und in dem Hauptprogramm benutzt Du dann nur die Interfaces, nicht die Implementierungen, so dass Du dann mit Fake-Objekten arbeitest, um ohne Abhaengigkeiten/Hardware zu testen oder Verhalten zu modifizieren.
Ausserdem kannst Du so leichter kleine Testprogramme schreiben, die einzelne Funktionen der Klassenbibliotheken testen.

TCP sichert immer die Reihenfolge und buffert, aber nicht besonders viel - das ist die Aufgabe des Protokolls, nicht der Anwendung. Geht etwas verloren, wird ein Requeue gemacht - das passiert aber auch, wenn Du zu langsam bist.
Ob Du mit Schleifen oder Threads besser dran bist, haengt vor allem von der Anzahl und dem Verhalten der Clients ab - bei wenig Clients, wenig Traffic, sind threads effizienter, bei vielen Clients und viel Traffic eventuell Schleifen. Senden wuerde ich auf jeden Fall in einer Schleife, nicht in einem Thread pro Client.

Die saubere Loesung waere das hier:
Codebase bei MSDN.
Du solltest Dir natuerlich bewusst sein, dass Du immer noch Probleme bekommen kannst, wenn sich die Versionsnummern der dll aendern.

Wenn Du %PATH% aendern kannst, koenntest Du dort die Referenzen auf die Verzeichisse fuer die DLLs anpassen, anstatt zu kopieren.

Diese Klasse hier ist ja nur der Container, der wohl nur pro Connection String genau eine Database Connection zurueckgibt.
Die Frage fuer Dich ist mehr, ob DatabaseConnectionWrapper in sich threadsicher ist oder nicht.
Threadsicher bedeutet nicht, dass jeder Thread eine eigene Connection/Instanz von DatabaseConnectionWrapper braucht.

Der Listener sollte in einem eigenen Thread laufen - da der Listener am besten blockiert, um Ressourcen zu sparen.
Ich wuerde dann fuer die Kommunikation zwischen GUI/Form (View) und Listener-Thread (Model) ein eigenes Object (Controller) implementieren, dass intern eine Thread-Safe Collection benutzt.

bOrderData ist immer false.

       // Die Funktion kann vom MainForm aus aufgerufen werden und setzt bOrderData auf true
          public void setOrderData()
        {
            bOrderData = true;
            System.Diagnostics.Debug.WriteLine("auf true gesetzt");
        }

Kannst Dich auch mit NuGet ausseinandersetzten, wenn Du es einfacher haben willst.

Ich wuerde an Deiner Stelle ueberlegen, dass Du mit Stored Procedures arbeitest, so dass Du flexibler gegenueber Aenderungen in der Datenbank ist - ausserdem wird es dann moeglich, dass SQL-Statement zu aendern, ohne eine neue C# Exe auszuliefern.

Pruef mal bei Sender, ob Du auch Flush aufrufst oder AutoFlush gesetzt hast.

Probier mal, ob der Stream

 Process.GetCurrentProcess().StandardOutput 

Deine Daten enthaelt.

Welche Excel-Version?
EPPlus ist gut und schnell, um Excel/Dateien zu lesen.

var newFile = new FileInfo("sample1.xlsx");
ExcelPackage p = new ExcelPackage(newFile);            
int i=0;
foreach (ExcelWorksheet ws in p.Workbook.Worksheets) {
     Console.WriteLine("sheet:" + i++ + " name:" + ws.Name);
}

muesste funktionieren...

Wuerde mir an Deiner Stelle mal FileSystemWatcher anschauen.
Mit einem Neuladen der "Standard-Konfiguration" habe ich schlechte Erfahrungen gemacht - ich wuerde Dir auf jeden Fall eine Custom-Section in der Konfig-Datei empfehlen.

Vereinfacht gesagt, kannst Du mit .NET 4.0 Runtime auch 3.5 Programme und Assemblies benutzen - selbst in einem Programm kannst Du Assemblies mit verschienenden CLR Versionen mischen - das Schlagwort lautet Side-by-Side Execution.
Umgekehr geht das nicht - da musst Du die version wieder runtersetzen und entsprechend anpassen.

Ich wuerde an Deiner Stelle nicht an den generierten Attributen etwas drehen.
Wenn Du etwas anderes haben willst, wuerde ich ein Wrapper Assembly machen, dass die Internal Assemblies nicht mehr sieht - aber der Wrapper fuehrt zu mehr Komplexitaet bei der Installation.

Dein lock muesste meines Erachtens nur um MapArray.Add (color, mapArray); stehen.
Ob sich Parallelisierung lohnt, haengt davon ab, wie lange WorldManager.Terrain.Heightmap [x * WorldManager.Terrain.ScaleFactor, y * WorldManager.Terrain.ScaleFactor] braucht - der Rest ist ja sehr schnell abgearbeitet..

Schau mal, wie ob Dir die Performance Counter im Perfmon gefallen - auf die koenntest Du zugreifen ohne Verrenkungen.

Im Process Explorer - "Rechte Maustaste - Create Dump" Dumps erzeugen.

Ich wuerde die Delegates bei der Definition initialisieren.
Beispiel:

public delegate MyDelegate(T parameter);
public MyDelegate MyDelegateProperty=delegate{//Dein Fehlercode}

Ich persoenlich benutze auch log4Net - es ist sehr flexibel, insbesondere, da es auch nette andere Appender gibt wie telnet oder man auch selber Appender schreiben kann. Durch die Struktur kannst Du gut trennen, zwischen dem Logging auf der Applikationsebene und der Konfiguration der Ausgabe je nach Anforderungen.
Ausserdem ist es sehr hilfreich, dass Du das Loglevel waehrend der Laufzeit aendern kannst und wenn Du z.B. die Logger mit Klassennamen versiehst, genau eine Klasse auf Debug-Logging zu stellen, um Fehler nachvollziehen zu koennen.

Die .NET Portierung lautet log4Net.
Ein Logger wird Dir aber nicht abnehmen, dass Du ein Verzeichnis beschreiben kannst...
Ansonsten solltest Du dein Problem konkreter beschreiben!

Fuer C++ kannst Du dumpbin benutzen...

Ich wuerde an Deiner Stelle mit ILSpy aus den Exe Dateien den IL-Code exportieren und vergleichen.

Du koenntest auch mit rsync arbeiten und regelmaessig die Verzeichnisse sichern und versionieren.