Ich denke, Du musst schauen, dass Deine Funktionen ueberall mit den gleichen Parametern wie Buffer.Copy arbeiten -d.h. immer byte[], offset und Nutzlaenge benutzen, so dass Du immer mit dem relevanten Ausschnitt arbeitest, ohne jemals zu kopieren...

Framework Design Guidelines ist ein sehr gutes Buch mit vielen Stilempfehlungen, die Du aber auch über MSDN findest - ansonsten wuerde ich mal empfehlen, Code zu schreiben, der von FXCop geprüft wird - FXCop ist die Implementierung des Buches als statische Code-Analyse.

Wahrscheinlich musste der Global Assembly Cache aktualisiert werden - je nach Sicherheitseinstellungen musst Du dafuer Admin sein oder nicht.

Ich wuerde mich mal mit dynamic beschaeftigen - vielleicht ist das genau das richtige fuer Dich....

Du beendest damit hart das ganze Programm, aber wenn die DLL nicht einen eignen Destruktor hat bleibt Dir nix anderes uebrig ausser dies und vielleicht nur die AppDomain der DLL mittels AppDomain.Unload zu entladen.

Am saubersten ist es, wenn Du selber ein Exception Klasse erstellst.
Exception Design Guidelines zeigt Dir, was zu beachten ist.

List<ITest> liste = new List<ITest>();
Dictionary<Type, double> Max = new Dictionary<Type, double>();
Dictionary<Type, double> Min = new Dictionary<Type, double>();

foreach(ITest item in liste)
{
  Type type = item.GetType();
  if (!Max.Contains(type))
    Max.Add(type, item.maxVersion);
  if (!Min.Contains(type))
    Min.Add(type, item.minVersion);
  if (Min[type]>item.minVersion)
Min[type]=item.minVersion;
  if (Max[type]>item.maxVersion)
Max[type]=item.maxVersion;

}

Die Instanzen einer Socket Klasse sind threadsafe - die Instanzen von Streamreader/writer wie TextReader/TextWriter sind nicht threadsafe! Gleichzeitig lesen und schreiben vom gleichen Socket ist möglich, solange Du kein accept machst/in listen Mode gehst...
Poste mal Deinen Code, ich verstehe so das Problem nicht.

Synchrones Lesen von Sockets in eigenen Threads ist meist schneller als die asynchronen Methoden, so gelesen in CLR via C#. Hintergrund ist, daß das asynchrone Programmiermodell zusätzliche Objekte benötigt und somit den Garbage Collector beschäftigt. Arbeitest Du mit einem eigenen Thread, kommst Du bei kluger Programmierung ohne ein new/Konstruktor aus und lässt den GC ruhen.

Der Server arbeitet schon asynchron. Falls Du zwischenspeichern möchtest, ist es am einfachsten, daß Du mit einer BlockingCollection als Zwischenspeicher arbeitet - so hast Du automatisch eine thread-sichere Verarbeitung.

Wenn Du anderherum aufrufst (C# ruft Delphi auf) und Du einen C# Delegate/Funktionpointer übergibst, dann musst Du verhindern, daß dieser C# Pointer vom GC eingesammelt wird - die Referenz im Delphi Code ist dem GC nicht bekannt. Dies machst Du am einfachsten, indem es eine zusätzliche Dummy-Referenz in C# gibt - zum Beispiel in einer statischen Variable.

So ganz habe ich das nicht verstanden, was Du machst....Aber wieso definierst Du nicht einfach ein Interface, dass Deine Objekte implementieren und benutzt dann an dieser Stelle das Interface?

EPPLus benutzt halt OpenXML - das alte Format ist propriatär, also nicht offiziell dokumentiert. Wer ein altes Excel hat, muss halt den Compatibility Pack installieren...

Ich bin ein Fan von EPPlus.
Edit: Umlaute funktionieren ohne Probleme....

Das Kapital ueber Threading in Clean Code ist sehr gut - vor allem, da schön erklärt wird, wie Threading das Design beeinflusst. Die vorher erwaehnten Quellen zeigen die Mechanismen, aber nicht, wie Du das am Besten einsetzt, um ein praktisches Problem zu loesen.

Ich denke, Du kannst Dir die Sache einfacher machen, wenn Du vor allem die Metadaten fuer ein Assembly benutzt und dann vorher sauber den Assemblynamen und Versionsnummer ausnutzt. So kannst Du auch einfacher pruefen, was Du getestet hast und was nicht und auch alte Version vorneweg pauschal zurueckweisen.
Das Du Exceptions abfangen musst, ist klar, aber Versionssnummern koennen Dir auch helfen, weil Exceptions ja auch durch Bugs entstehen koennen.

Ich denke nicht, dass Du die Spaltenbreite automatisch anpassen kannst - das geht auch nicht ubers GUI als quasi Neuberechnung - was es gibt ist ShrinkToFit - sowohl uebers GUI als auch ueber OpenXML.

COM ist typesicher, also musst Du die Definition von CATSafeArrayVariant finden und kannst nicht einfach double benutzen.
Schau Dich mal mit OLEView um, oder Du musst die IDL Definition von CATSafeArrayVariant/CATSafeVariant finden...
Wenn Du etwas gefunden hast, dann kannst Du mit MIDLeine type library (.tlb) Aus der .tlb, kannst Du dann mit tlbimp.exe C# Imports generieren....
Ansonsten wuerde ich auch schauen, ob es nicht Hilfsfunktionen gibt, die Dir das Array bauen. Dann kannst du u.U. die ganzen Typecasts ganz elegant durch das dynamic Keyword erschlagen, indem Du statt des jeweiligen Typen analog den Variants von VBA die Variablen als dynamic bezeichnest - das geht aber nur in .Net 4.0 und nur wenn Du eine Funktion hast, die Dir das zurueckgibst.

Du musst auf den Socket die Socket.ReceiveTimeout Property auf einen Wert setzen, so dass ein Timeout eine Socket-Exception auslöst.
Ansonsten solltest Du entweder einen Task verwenden oder einen echten Thread starten und die vorher beschriebene BackGround Property setzen.

Die Laufzeitumgebung ist immer abwaerstkompatibel und unterstuetzt auch, dass die Assemblies mit verschiedenen Versionen nebeneinander arbeiten.
Folgender Link erklärt Dir gut dieSide-by-Side Execution.

Ich wuerde Dir raten, JSON Serialisierung aus dem Framework anzuschauen.
Siehe JSON-Serialisierung Beispiel auf MSDN

Ich denke, dass UDP Broadcast gewählt wurde, da es an sich keinen Server geben soll. Wie soll das Spiel denn mit nur einem Client funktioneren?
Ich würde Dir trotzdem raten, mal mit einem TCP Server/Client Modell anzufangen, da dass einfacher als UDP ist. Dann musst Du halt auf einem Rechner Server und Client implementieren, aber so sind dann die Rollen klar. (Oder hast Du schon Client/Server implementiert?)

Fogbugz koennte auch etwas fuer Dich sein...

Ich hatt es kurz ueberflogen, ich moechte gerne, dass das aufrufende Programm nicht wissen muss, wo die Daten fuer die DLL liegen - das ist mein Problem..

Nicht unbedingt - ich benutze die DLL zurzeit 3 mal - einmal für die manuelle Test-Anwendung, einmal für den Unit-Test und einmal in einer Konsolen-Anwendung. Ich würde ungern alles gezwungenermassen in gleichen Verzeichnis wie die exe halten...
Außerdem möchte ich nicht, dass die aufrufenden Programme den Pfad zu den Dateien kennen müssen...

Ich habe eine Class Library entwickelt, dabei benoetigt die DLL mehrere Dateien mit serialisierten Objeken - wie kann ich ohne statisch den Pfad in die DLL zu schreiben, den Pfad setzen?
Wuerdet Ihr mit einer Umgebungsvariable arbeiten oder bietet sich etwas anderes an? Das normale Applikationsmodell deckt das meines Erachtens nicht ab.

Hallo,
ich benutze in meinem Programm ein Dictonary, dass ich gerne in eine Klasse umwandeln muss.
Reicht es, dass ich das IDictionaryInterface implementiere, so dass weiterhin die Array-Schreibweise beim Zugriff funktioniert oder geht das nicht?

Hast Du glib 2.x (http://www.gtk.org) and pkg-config (http://www.freedesktop.org/software/pkgconfig) vorher gebaut? Ich hatte so vor 2 Monaten unter Linux/CentOS keine Probleme, bei Solaris unter Sparc habe ich dann aber recht schnell die Flinte ins Korn geworfen...

Ich wuerde Dir "Microsoft .NET Framework-Programmierung in C#. Expertenwissen zur CLR und dem .NET Framework 2.0" von Jeffrey Richter empfehlen.
Dort wird genau hinter die Kulissen des Frameworks geschaut.
Ansonsten ist Performance-Tuning vor allem Messen und das Finden von Bottlenecks...

Hallo,
Ich moechte gerne, dass sich ein Consolen-Programm aus sich selbst bei einem Verbindungsabbruch mit dem Server beendet und wieder startet. Hintergrund ist, dass ich eine DLL benutze, die keinen sauberen Restart unterstuetzt.
Wie kann ich das realisieren?

Es wird folgende Exception geworfen:
Die DLL Test123.dll: Das angegebene Modul wurde nicht gefunden (Ausnahme von HRESULT: 0x.....) Kann nicht geladen werden.

Die DLL wird nicht gefunden, die DLL musst Du im PATH oder im BIN Verzeichnis direkt haben.

Unter Unix kann man die Signale abfangen - klappt auch ganz gut - ist vor allem auch praktisch, wenn man ohne grossen Aufwand das Programm umschalten moechte - zum Glueck kann Log4Net auch dynamisch auf Aenderungen im Config-File reagieren...

Wie kann ich in einer Consolen-Anwendung vor dem Abbruch durch Ctrl+C oder durch Stoppen in den "Geplanten Tasks" noch eine Methode aufrufen, damit ich in meinem Logfile die Statistiken fuer den Tag wegschreiben kann. Ich stehe da etwas auf dem Schlauch und die Suche hat mich auch nicht weitergebracht...

Ich wuerde mir mal CHESS ansehen...
CHESS.
Vielleicht hilft das. Ansonsten hilft nur Loggen und anschauen und nochmals anschauen - ich habe aber auch mal einen ganzen Tag einen Deadlock gesucht, der zustande kam, weil ich zwischen zwei locks geloggt habe 😉

Ich moechte LINQ gerne benutzen, um fuer mein Performance-Monitoring aus einer Liste statistische Werte (Durchschnitt, Median, Schnellster und langsamster Wert) zu bestimmen.
Meine Klasse sieht ohne LINQ wie folgt aus:

    static public class TransactionMonitoring
    {
        class Transaction
        {
            string Caller;
            DateTime Started;
            DateTime? Ended;

            public Transaction(string caller)
            {
                Caller = caller;
                Started = DateTime.Now;
            }

            public void Finish()
            {
                Ended = DateTime.Now;
            }
        }
        static private Dictionary<int, Transaction> TransactionList = new Dictionary<int, Transaction>();

        static public void StartTransaction(int id)
        {
            System.Diagnostics.StackTrace stacktrace = new StackTrace();
            String Caller = stacktrace.GetFrame(1).GetMethod().Name;
            TransactionList.Add(id, new Transaction(Caller));
        }

        static public void EndTransaction(int id)
        {
            TransactionList[id].Finish();
        }

    }

Was wuerdet Ihr mir da vorschlagen? Die Werte muessten dabei nach Caller gruppiert werden oder muss ich alles per Hand machen?

Du musst konkret im Code folgende Zeile verwenden.

log4net.Config.XmlConfigurator.Configure(new System.IO.FileInfo(Configuration.Log4NetConfigFile));

Ich habe ein manchmal ein vergleichbares Problem, wenn ich statt der App.config mit XML Dateien arbeiten muss/will, da ein User mehrere Instanzen einer Applikation startet und da dass m.E. nicht in das .NET Modell passt..

Wie schaut Ihr Euch unter Windows Logfiles an, die sich staendig veraendern ala tail -f unter Linux/Unix? Ich habe die Powershell installiert, aber damit bekomme ich das nicht hin.
PS Falls es ein besseres Unterforum gibt, bitte verschieben...

100 % sicher - Meine Anwendungen funktionieren wirklich als Middleware und filteren und priosieren dabei nach hinten weiter. Dabei messe ich sowohl die empfangenen Nachrichten und begrenze die Anzahl nach hinten und schreibe immer in meinem Log die Anzahl der Updates pro Sekunde und wenn nach hinten die Updates priorisiert werden.
Der Server auf der Gegenseite ist in Java geschrieben und der hat schon mal Aussetzer von ein paar Sekunden alle 3-4 Stunden. In .NET und auch in Mono sind die Spitzen besser verteilt.
Ansonsten kommt es vor allem auf die Applikation an - zum Beispiel werden bei mir die Dictionaries schon mit Grössen vor-initialisiert und während der (eigentlichen) Laufzeit werden nur die Werte, aber nicht die Schlüssel verändert.

Klar - es muss alles in Echtzeit sein - jede Schlange wird im Zweifel laenger und laenger...

Die Anwendungen, die 2000-3000 Updates pro Sekunde abnehmen und in Dictionaries ablegen, gibt es schon. Die eine basiert auf ein einfaches string-basiertes Protokoll mit Trennzeichen. Dort habe ich Spitzen bei ca. 25.000 Updates pro Sekunde gemessen.
Die andere Applikation bekommt die Daten aus einer DLL und die ist ebenfalls sehr schnell und erzeugt sehr wenig Last.
Das mit dem Remoting werde ich mir mal anschauen und ebenfalls messen.
Ich habe auch sehr gute Hardware (Opterons) und da geht schon so einiges, was ich nicht fuer moeglich gehalten haette...

Hallo!
Ich moechte gerne ein Dictionary mit einem String als Key und 4-5 Double zwischen 2 Programmen, die eventuell auf unterschiedlichen Rechnern sind, performant synchronisieren. Was wuerdet Ihr fuer eine Protokoll/Bibliothek nehmen?
Zwischen den Programmen muessen mehrere Tausend Updates pro Sekunde verarbeitet werden.

Mir war das aus Versehen passiert, da ich wusste, dass alle Socket Methoden threadsicher sind - insofern hatte ich erwartet, dass dann auch Network-Steam threadsicher ist, aber dem ist nicht so...
Ein lock um den Zugriff rum ist ja nicht so schwer/schlimm...

Ich hatte das Gefuehl, dass beim Benutzen von Network-Stream aus mehreren Threads die Daten aus den beiden Threads vermischt werden - so war das zumindest unter Mono.

Jeder Thread sollte eine eigene Instanz von StreamReader haben oder Du musst tatsächlich mit lock arbeiten, denn Streamreader ist nicht thread-safe. (Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.) Mir ist letzte Woche etwas ähnliches mit NetworkStreamWriter passiert...

Log4Net funktioniert gut unter .NET und Mono mit einem Quellcode und es ist auch wirklich performant...

Danke für das Feedback - werde dass dann auch umstellen und meine Erfahrungen teilen.

Hat jemand von Euch Erfahrungen gemacht, wenn die gleiche Anwendung unter mono und unter .NET laeuft und das Logging mittels log4net erfolgt?
Geht das mit einem Quellcode oder muss ich irgendetwas besonderes beachten?

Bei den Thread-Geschichten in Büchern wird meistens sehr konstruiertes Zeug gemacht, anstelle wirklich die wichtigen Patterns (Boss/Worker, Work Crew und Pipeline) zu erklären. Rühmlich Ausnahme ist das tolle Buch von Richter, dass viele Details im Hintergrund erklärt (insbesondere den Preis von Kontext-Wechseln).
Die Thread-Priority ist etwas klassisches, was man in der Konfiguration eines Programmes festlegt.

Die Threads sind in mehren DLLs versteckt, die ich auch fuer verschiedene Aufgaben benutze und da ist fuer mich Destruktor/Dispose das richtige um das zu beenden.

Die Server-Komponente hat in ihren Konfigurationsparametern eine Schlusszeit, zu der sie sich beenden muss, da es von der Geschaefts-Logik keinen Sinn mehr macht, auch wenn die technische Verbindung noch da ist.
Der Main-Thread startet die verschiedenen Threads (Pipeline-Modell) und wartet dann einfach bis zur Schlusszeit und beendet dann alles mit System.Environment.Exit(0);
Das Ding verarbeitet mehrere tausend Nachrichten pro Sekunde und es laeuft auch unter Mono sehr schnell und stabil.