Wenn Du eine hoehere CPU Auslastung sehen willst, ohne dass das Programm schneller laufen will, dann musst Du nur den ServerMode fuer den Garbage Collector einstellen.
Du musst mit einem Tool wie dem Process Explorer genauer Deine Applikation untersuchen, um ein Gefuehl fuer den Engpass zu bekommen. Die CPU ist es wohl nicht.

Ich habe mich vor einiger Zeit auch mit einem aehnlichen Problem herumgeschlagen, dass ich immer Exceptions bekam beim Beenden des Programmes.
Deine Dispose Methode erzeugt wahrscheinlich einen Deadlock und ist in jedem Fall ohnehin nicht threadsafe.
Das Aufraeumen/Beenden der Threads laeuft automatisch beim Stoppen des Programms.

Sorry, Du hast recht - also muesstest Du Treenode binaer serialisieren.

Geht natürlich nicht, weil TreeNode nicht serialisiert werden kann! (Richtig??) Treenode implementiert ISerializable und hat das Serializable-Attribute.
Deine abgeleitete Klasse von Treenode muss nun aber auch ISerializable implementieren und das entsprechende Attribute gesetzt haben.
Deine Implementierung von Serializable kann natuerlich einfach auf die Implementierung der Basisklasse zurueckgreifen.

So wie ich verstanden habe, schreibt ihr die generierten Daten des BinarySerializer in die Datenbank - richtig?
Ohne Versioning fuehrt jedes neue Feld dazu, dass der Serialiserer die alten Daten meistens nicht mehr lesen kann.
Du hast nun die Moeglichkeit mit [OptionalField (Version Added = 2)], die neuen Daten zu markieren, so dass Du mit dem neuen Assembly die alten Daten aus der Datenbank lesen kannst. Wahrscheinlich musst Du dann fuer die neuen Felder eine Routine schreiben, so dass die Felder berechnet oder initialisiert werden und dann zurueckgeschrieben werden - aber das kommt jetzt auf die Daten an.
Ergo wirst Du ein Assembly mit Versioning brauchen, aber auch eine neue .exe fuer die Datenkonvertierung.

Ich bin ein grosser Fan von ProtoBuf.Net. Insbesondere das es sehr schnell ist, da mit einigen sehr cleveren Low-Level Tricks sehr viel Performance erreicht wird - der Serialisierer ist so z.B. ein vielfaches schneller als der BinarySerializer im Framework. Eine Feature Liste findest Du in Capabilities - protobuf-net - What features does protobuf-net support.

Es gibt dort auch eine optionale Moeglichkeit Referenzen zu serialisieren, aber das geht dann nur innerhalb von .NET, da es ausserhalb vom Standard-Protokoll ist (daher optional).

Fuer den Fall wuerde ich mich mit ConcurrentCollections beschaeftigen und darueber die Kommunikation zwischen den Threads realisieren.
Damit kannst Du das Thema Locking umgehen. Welche der Klassen am besten passt, kommt genau auf Deine Anforderungen an.

Einfaches Beispiel fuer einen Task inklusive Warten.

static void Main()
{
  var task = Task.Factory.StartNew (Greet, "Hello");
  task.Wait();  // Wait for task to complete.
}

Falls Du Englisch verstehst, wuerde ich mir das Tutorial von Albahari anschauen.

Debuggen mit Threads ist immer eine knifflige Sache.
In Deinem Fall ist es bedeutend einfacher, wenn Du Parallel.Foreach benutzt. So solltest Du ohne große Probleme Deinen Code parallelisieren können.

Der DataPublishWizard wurde eingestellt (Siehe die Note beim Link).
Du musst im SQL Server Studio mit der rechten Maustaste auf die Datenbank klicken und "Task"-"Generate Script" ausführen.

ServerList solltest Du in eine ConcurrentList umwandeln, das wird aber u.U. noch mehr Änderungen nach sich ziehen.
Eine Liste ist nicht threadsafe und wenn Du parallel foreach und add auf die gleiche Liste ausführst, dann gibt es die von "Collection was modified" Exception.

Normalerweise muesstest Du anhand des Stacktrace sehen, bei welcher Collection es das Zugriffsproblem gibt - die saubere Lösung wäre es, daß Du diese Collection in eine ConcurrentCollection umwandelst, so daß die Iteratoren und Zugriffe durch das Framework synchronisiert werden.

Hallo Kroax,
Herbivores Einwand mit dem deklarative Programmieren teile ich.
Ich bin gerade dabei F# mit dem Buch von Chris Smith zu lernen. Dabei wird im ersten Abschnitt "Multiparadigm Programming" in der Abfolge Basiselementen, funktionale, imperative und objektorientierte Programmierung mit F# erklärt. Das passt vielleicht besser zu der Sprache, da F# als .Net Sprache gezwungenermaßen mehrere Paradigmen unterstützt. Ich denke, daß dass der bessere Aufbau ist.

In der ECMA Spezifikation steht nur

The lock statement obtains the mutual-exclusion lock for a given object, executes a statement, and then releases the lock.
lock-statement:
lock ( _expression _ ) embedded-statement
The compile time type of the expression of a lock statement shall be a reference-type or a type parameter (§25.1.1) known to be a reference type. It is a compile-time error for the compile time type of the expression to denote a value-type.

A lock statement of the form

   lock (x) …   

is precisely equivalent to:

object obj = x;   
System.Threading.Monitor.Enter(obj);   
   try {   
      …   
   }   
   finally {   
      System.Threading.Monitor.Exit(obj);   
   }   
  

[Example:

   class Cache   
   {   
    public void Add(object x) {   
        lock (key) {   
           …   
        }   
    }   
    public void Remove(object x) {   
        lock (key) {   
            …   
        }   
    }   
    private readonly object key = new object();   
}   

end example]

The lock statement obtains the mutual-exclusion lock for a given object, executes a statement, and then
releases the lock . Also musst Du Dir wegen einem Deadlock keine Sorgen machen. Wuerde den Locker nur nicht statisch deklarieren, weil jede Instanz der Klasse seinen eigenen Lock benutzen sollte.

Ich habe eben in der Eile etwas uebersehen.
Das Problem ist in dem Fall hier, dass Dein Property ein Array und damit eine Referenz ist.
Also geht das leider nicht ganz so einfach mit dem privaten locking.
Die sicherer Sache waere bei einem get eine Kopie des Array zurueckzugeben.

Ein lock sollte schon reichen.
Wichtig ist, dass das lock am besten privat im Objekt gehandhabt wird, dann musst Du nur eine Klasse verändern und nicht jede aufrufende.
Du solltest Deine public Properties natürlich dann ändern.
Der Code sähe ungefähr so aus:

public class xxx{
private object locker=new object();
private UInt32[]  _statuswordSegment;
public UInt32[] StatuswordSegment {
get {
  lock (locker) {
     return _statuswordSegment;
   }
set {
  lock (locker) {
     _statuswordSegment=value;
  }
}
}

Ich habe so etwas aehnliches vor kurzem mit xsd2code.exe auch probiert und es hat auch nicht funktioniert - der XML Serialisier vom Framework kann nur seine eigenen XML-Dateien deserialisieren - er faellt schnell auf die Nase, wenn es kleine Abweichungen gibt.
Ich wuerde an Deiner Stelle partial classes generieren und dann das Deserialisieren selber schreiben. Hier ein Beispiel.

Welche Klasse benutzt Du denn genau?
Normalerweise solltest Du anhand connected Eigenschaft des Sockets oder anhand der IOException beim Read/Write sehen, dass Du abgehangen bist.
Wuerde an Deiner Stelle aber immer fals moeglich selber ping/keepalive implementieren, da das Protokoll an solchen Stellen intransparent ist.

Ich mache den Upload mit webClient so...

var webClient = new WebClient{
                                   Proxy=null,
                                   Credentials=new NetworkCredentials(userName, password),
                                   BaseAddress=ftpServerBase);
var remoteUri = ftpServerBase + path + fileName;
webClient.UploadFile(remoteUri, fileName);

ftpServerBase sieht so aus ftp://adresse.

Nein - schau mal hier.
Es geht ja auch um die Identitaet...

Bei der Parallelisierung geht es mehr darum, dass ohne Seiteneffekte der Compiler/Betriebssystem mehr/besser optimieren kann, nicht so sehr um den Algorithmus als solches. Bestes Beispiel sind dazu Rekursionen - in funktionalen Sprachen sind rekursive Lösungen manchmal schneller als iterative (Stichwort Tail Optimikerung), während es in den traditionellen Sprachen andersrum ist. Zurzeit sind vor allem die Speicherbusse und Cache Größen das Problem, was das Wachstum der Kerneanzahl pro CPU bremst. Aber auf richtigen Servern wächst die Zahl der Hardware-Threads immer weiter.

Um zum Urspungs-Thema zurueckzukehren - Vorteile beim funktionalen Stil sieht man vor allem da, wo der Overhead von der Objektorientierung groß ist - typisches Beispiel fuer mich ist, wie man vor Linq/Lambdas und vor allem vor den Generics Sortierung in C# implementieren musste und wie locker/leicht und intuitiv nun mit Linq sortiert wird...
Der andere grosse Vorteil/Nachteil liegt im Wechsel vom imperativen zum deklarativen Programmierstil.

Wuerde auch mal xsd2 probieren, um die Klassen zu generieren. Bekommst Du da Klassen raus? xsd2 funktioniert auch über mehrere xsds hinweg.
Manchmal gibt es Probleme, dass das Serialisieren/Deserialisieren nur händisch klappt, aber wenigstens hast Du dann wenigstens die Klassen und Properties in einem standartisierten Format und da xsd2 partial classes schreiben kann, kannst Du das Ergebnis von xsd2 gut mit eigenem Code verbinden.

Mono läuft wohl auf Raspberry, siehe Mono Working on Raspberry Pi?.
Siehe auch Mono on Raspberry Pi.

An Deiner Stelle wuerde ich erstmal das Thema starker einschränken, da Du bei einer Facharbeit wahrscheinlich sehr stark eingeschränkt bist, was Zeit und Umfang anbetrifft. So würde ich mich entweder nur auf C# oder F# beschränken.
Real World Functional Programming geht sehr genau in die beschriebene Richtung von Deiner Arbeit.
Vieles von dem Buch findest Du mittlerweile auch bei MSDN.
Das neue Buch F# Deep Dive ist leider noch nicht so weit, daß es so sinnvoll für Deine Arbeit ist.

Andere Moeglichkeit ist mit COM Interop auf den IE zurueckzugreifen - es gibt viele Moeglichkeiten, was Du machen kannst...

Du hast ein typisches Producer/Consumer Pattern und da wuerde ich auf eine BlockingCollection zurueckgreifen.
Der Producer koennte zum Beispiel an den Consumer einen Parameter mit der Ergebnis-BlockingCollection mit. Der Consumer schreibt dann sein Ergebnis in die Collection (Add-Methode) und der Producer wertet das Ergebnis aus (Take auf die Collection) und prueft nach jedem empfangenen Ergebnis, dass keine weiteren Ergebnisse ausstehen.

Wahrscheinlich meinst Du einen HTTP Proxy - also so einen Proxy wirst Du nicht benutzen können, da HTTP auf TCP aufbaut und nicht umgekehrt.
Was ist denn genau Dein Problem?

Ich sehe nirgendwo Test bei der Visual Studio 2012 Express Desktop Edition.

Die Express-Version ist umsonst, aber Du solltest Sie trotzdem registrieren - dann sollte die Test-Einschränkung verschwinden.

Schon mal

System.Text.ASCIIEncoding enc = new System.Text.ASCIIEncoding();
   SetValue("blub", enc.GetString(new byte[]{0x55, 0x46, 0xFE, 0x32}), RegistryValueKind.String); 

probiert?

Die Methode hat die Signatur

SetValue(String, Object, RegistryValueKind)

• ergo kannst Du schon Binary und RegistryValueKind.String mischen. Musst Du halt testen.

Schau Dir mal TPL Data flow an. Der Ansatz der Bibliothek sollten zu Deinem Problem passen.
Selber habe ich noch recht wenig Erfahrung mit der Bibliothek.

Wie greifst Du denn darauf zu?
Das Registry Beispiel zeigt Dir, wie Du Wert und Werttyp setzt.

Benutze auch Keypass.
Dass man auf jeder Seite heutzutage ein eigenes Password braucht, sollte selbstverständlich sein. Ich finde die 2 Step Anmeldung bei Google gut und denke, dass sich so etwas langfristig durchsetzen wird.

An Deiner Stelle wuerde ich vor allem mehr Logging in den Code einbauen, so dass Du anhand des Loggings nachvollziehen kannst, wann ein Backgroundworker beginnt und startet und auch die Parameter sehen kannst, mit denen Dein Backgroundworker loslegt.
Ansonsten koenntest Du auch mit dem Debuggger den entsprechenden Thread anhalten.
Hast Du schon geschaut, ob die Exception Counter hochgehen, wenn Du das Problem hast?

Debuggen wirst Du nur koennen, wenn Du passende pdb Dateien fuer die jeweiligen Klassen hast.
In solchen Faellen bist Du oft besser dran, wenn Du mehr mit Logging arbeitest und entsprechend den Loglevel aufdrehst.

Beschreib mal, was Du genau machen willst. Fuer mich hoert es sich so an, als versuchst Du geerbte Stream-Methoden auf FileStream anzuwenden, die nicht unterstuetzt sind oder zum Beispiel in der Mitte und am Ende der Datei gleichzeitig zu schreiben.
Wenn es um eine performante Zwischenablage geht, kommst Du mit einer InMemory-Datenbank bestimmt besser und einfacher weg.
Wenn Du dagegen alles nachvollziehbar halten musst, auch wenn der Rechner komplett heruntergeht, dann musst Du einfache Transaktionslogs schreiben.

Als Referenz kann ich C# in a Nutshell empfehlen - von den Autoren stammt auch das LINQPad - das ist ein klasse Tool fuer LINQ. Das Network-Kapitel ist knapp und gut - an dem Buch beeindruckt mich immer die Qualitaet der Beispiele - kurze Beispiele mit kurzen, aber auch klaren Erklaerungen.
C# in Depth erklaert Dir viele Hintergruende zu LINQ - kommt halt darauf an, wie tief Du einsteigen willst. Dieses Buch ist keine leichte Anfaengerkost, aber da wird alles super und in Tiefe erklaert.

Wenn es Dir nur ums reine Serialisieren/Deserialisieren geht, dann wuerde ich auf Protocol Buffer zurueckgreifen...Bei mir war der Performance-Unterschied zum Microsoft BinaryFormatter ca. bei Faktor 10 (3 vs 30 Sekunden).
Die Umstellungen zum Binary Serialiser sind ueberschaubar, einziger Kniff ist, dass Du bei den Serialisierungsattribute Positionsnummern beginnend mit 1 vergeben muss.

Eine wichtige Frage ist das Deployment. Dass Config-Modell von .NET passt halt zu den Benutzerrechten und -ordnern fuer Windows.
Fuer die Dependency Injection ist es am wichtigsten, dass Du nur moeglichst im Application Root auf die Settings zurueckgreifst - in den zu testenden Klassen solltest Du dann die Werte immer indirekt uebergeben.

Eine Idee waere, dass Du Dir mit xsd.exe ein XML Schema erzeugen laesst und dann das Schema auswertest, um dynamisch die passenden XML Serialisierer zu erzeugen.

Gebe FZelle auch absolut recht.
Multithreading macht nur Sinn, wenn Du Dinge wirklich parallelisieren kannst, ohne den Overhead durch Synchronisation zu erhoehen.
In Deinem Fall wird es eher langsamer werden, wenn Du parallelisierst, da sowohl die Datenbank als auch deine SQL -Statements synchronisiert werden muessen.
Wahrscheinlich bist Du mit einem sqlbulkcopy in eine Staging Tabelle am schnellsten, wonach Du danach mit einem UpdateStatement die Daten aus der Staging Tabelle in die Zieltabelle aktualisierst. Die Staging Tabelle kannst Du dann anschliessend wieder loeschen.
Bei Deinem jetztigen Vorgehen sind auch so Dinge wie ein Neustart nach einem Absturz ein Alptraum, da Du nie weisst, welche Datensaetze schon geaendert worden sind und welche nicht.

Seit .NET 4.5 gibt es gcAllowVeryLargeObjects als Setting - damit wird einiges moeglich, was vorher nicht ging....

Ein bisschen kommts auch drauf an, was die Bibliotheken machen - musst Du Zeiger uebergeben oder nur Werte?
Bei Werten wirst Du ok sein, wenn Du statt mit int mit den jeweiligen 32/64 bit Typen wie int32/int64 arbeitest.
Bei .NET gibt es an sich keine unterschiedliche Kompilierung, sondern nur im PE-Header ein Flag, das angibt, ob die Anwendung 32, 64 bit oder Any ist.
Bei Any wird dann auf die anderen Assemblies geschaut.

Die Parser sind wichtig, wenn Du eine komplizierte Grammatik in BNF Form oder einer Domain-Specific Language definieren kannst. Solche Parser sind nicht sehr performant.
An Deiner Stelle ist es wichtiger, dass Du schrittweise Deine Suche verfeinerst und Regeln findest fuer die Nicht-Standardfaelle findest, so dass Du dann einen Datensatz mit verschiedenen Regular Expressions versuchst zu parsen.

Hast Du mal im ILSpy den IL Code angeschaut und auch zwischen 32 und 64 bit verglichen? Mein Verstaendnis ist, dass bei der Complilierung nur der PE Header anders ist.
Bei den GC aendert sich mit jedem Release recht viel - unter welcher Version hast Du denn getestet?

Ich wuerde es etwas anders formulieren.
In Java und in .NET solltest Du logisch unterscheiden zwischen der Sprache, dem Bytecode / Intermediate Language und der Runtime.
Ein Byte in C# ist demnach ein 8-Bit Unsigned Type. Ob dann die Runtime das C# byte wie ein natives byte implementiert, ist nicht direkt definiert.
In Java braucht man oefters die nativen bytes, da manche Klassenbibliotheken schlechter als in .NET implentiert sind.

Das Kompilieren unterscheidet sich nicht wirklich zwischen x86 und x64, da ja immer Bytecode erzeugt wird, der platformunabhaengig ist.
Mit Corflags kannst Du das entsprechende Flag in Deiner Exe setzen, so dass die .exe im x86 oder x64 Modus ausgefuehrt wird.

Da Du das Testprojekt wohl nicht ausliefern wirst, wuerde ich im Zweifelsfall in ein anderes Projekt auslagern.
Ansonsten musst Du eine eigene Implementierung von IErrorHandler fuer das Testen schreiben, was deutlich mehr Arbeit als Moq ist.