Wer kennt es nicht, in der Entwicklungsumgebung funktioniert die programmierte Software einwandfrei, auf einem anderen Testrechner aus unbekannten Gründen leider nicht mehr.

Um den Fehler schnell zu finden bieten sich Logfiles an. Gut dass .Net von Haus aus die Klasse Trace im namespace System.Diagnostics eine Lösung bietet.

Eine kleines Beispiel:

1. in der App.config den Tracer hinzufügen:
   [crayon-6767a17401f8b636579265/]
    
2. Neue statische Classe erstellen:
   [crayon-6767a17401f95722914879/]
   Nun kann man mit z.B: Logger.Info(„Programmstart“,“Main“) im Programmcode  Informationen an die application.log Datei anhängen. Das tolle auch das Datum wird nun mit übertragen.

Ein Event oder deutsch Ereignis ist immer an einen Delegatentypen gebunden, welcher wiederum eine bestimmte Signatur von (Rückgabewert + Parameter).

Ungefähr, stellt es dieses Muster da:

Zuerst brauchen wir einen delegaten. Jetzt stellt sich die Frage, die Methoden, auf die der Delegat später verweist, wie soll die aussehen? soll sie einen Rückgabewert haben? Soll irgend ein Wert an die Methode übergeben werden? Ja? Dann brauchen wir Parameter. Um das noch ein wenig verständlicher zu machen, wenn wir eine for-Schleife haben und wollen, dass das Event nach jedem Schleifendurchgang immer abgefeuert wird, und uns den Wert liefert. Dann würden wir einen Delegaten mit einem Parameter vom Typ int z.B. machen.
[crayon-6767a174024d7096728402/]
 

Dann braucht man das Event an sich. Dieser muss vom Typ des Delegaten sein.
[crayon-6767a174024dc138614090/]
 

Jetzt muss gesagt werden, wann das Event abgefeuert werden muss. Und, wichtig, wir haben dem Delegaten einen Parameter (int a) angegeben. Dieser Parameter muss nun durch das Event gefüllt werden. Das machen wir, indem wir
[crayon-6767a174024de849337171/]
Jetzt wird bei jedem Schleifendurchgang das Event abgefeuert.

Ok, das war unsere Quell klasse.

Jetzt erstellen wir ein Objekt dieser Klasse und weisen dem Event eine Methode zu, die ausgeführt werden soll, sobald das Event abgefeuert wird. Die Methode muss die selbe Signatur haben wie unser Delegat. Zum Schluss müssen wir die Methode in der Quell klasse ausführen und das Event wird abgefeuert und führt ebenso die Methode mit dem Parameter aus, die wir in der Ziel Methode eingegeben haben.
[crayon-6767a174024e0809274272/]
[crayon-6767a174024e2451747603/]
 

Download Beispielprojekt Eigener Event

Das .Net Framework beinhaltet bereits Delegaten, welche bestimmte Signaturen haben.

1. Der EventHandler

stellt einen Delegaten dar, der keinen Rückgabewert hat (void), und 2 Parameter hat. 1. Ist der object sender , welcher das Senderobject implementiert und EventArgs[] welcher evtl. Argumente beinhalten kann. Diesen Delegaten findet man, wenn man zu einem Event von Steuerelementen eine Methode aufruft.

2. Action<>

Der Action Delegat besitzt keinen Rückgabewert, wohl aber bis zu 16 Parameterelemente. Dieser Delegat kann z.B. dazu verwendet werden um eine Methode mit der Task Klasse aufzurufen und diese im neuen Thread zu starten.
[crayon-6767a17402738831220354/]
Das geht natürlich auch mit anonymen Methoden
[crayon-6767a1740273c730460979/]
3. Func<>

Der Func Delegat ist dem Action<> Delegaten gleich, liefert im Gegensatz zu ihm aber einen Rückgabewert

Manchmal möchte man wissen, wie lange mein Computer braucht um einen bestimmten Code auszuführen. Hierzu könnte man natürlich DateTime.Now für die Operationen verwenden. Allerdings ist dieser Wert ungenau. Einen Genaueren Wert erhalten wir mit dem Stopwatch. Dieser funktioniert aus recht simpel:
[crayon-6767a17402976253214907/]
[crayon-6767a1740297a067749894/]
 

Oft findet man im Code ewig lange if – else Verzweigungen, die zuviel Platz einnehmen und irgendwann die Übersicht rauben.

Die beiden Operatoren ? : und ??  sehen merkwürdig aus, sind aber in der Handhabung sehr praktikabel.

Der ? : prüft ob der Wert true ist. Falls ja, zählt der linke Wert, wenn nicht, zählt der Wert rechts davon.
[crayon-6767a17402b2b694627968/]
Der ??  Operator prüft, ob der Wert null ist. Bei nein, zählt der linke Wert, bei ja der rechte.
[crayon-6767a17402b2f723332147/]

Das ganze in lang könnte so aussehen:
[crayon-6767a17402b30435427218/]
[crayon-6767a17402b32542520811/]
Ab C# 6 soll noch das Feature hinzufügen, dass auch das „Elternobjekt“ geprüft werden kann, ob dieser nicht null ist.
[crayon-6767a17402b33970688204/]
 

TSQLmod Download

Klasse db (Connection String)

benötigt in erster Linie die SQL Instanz. Nachdem das Objekt erfolgreich initialisiert wurde, wird auch gleichzeitig die Verbindung aufgemacht und die folgenden Methoden können genutzt werden.

LookUP(…)

gibt aus einem SQL Query den ersten Treffer der angegebenen Spalte als String wieder. Ideal um einen Wert aus der Datenbank auszulesen. Möglich ist es entweder die Spaltennummer oder den Spaltennamen anzugeben.

getRowList(…)

gibt eine List<string> oder generische List<T> von der angegebenen Spalte zurück. Man erhält quasi aus dem Select eine gewünschte Spalte

getRowStringBuilder(…)

ähnlich wie die getRowList(…) ist der Rückgabewert aber ein Stringbuilder, in welchen alle Zeilen einer selektierten Spalte enthalten sind.

getDynamicList(…)

erfordert eine Klasse welche dieselben Datentypen und Bezeichnung hat wie das SQL Select. Als Rückgabe erhält man man eine List<meineKlasse>, welche 1:1 so viele Elemente und Spalten hat wie das Sql Query. Das ganze arbeitet nicht mit Reflektionen, sondern nach dem Prinzip von diesem genialen Autor: KLICK

Dazu jeweils ein Beispiel. Ausgehend vom folgenden Select:

einem erstellten Objekt der Klasse db:
[crayon-6767a17402e2c605527680/]
und ein string mit folgendem select:
[crayon-6767a17402e3b953323645/]

LookUp(…)

[crayon-6767a17402e3f030240036/]
 

Antwort: 

getRowList(…)

[crayon-6767a17402e43237476488/]

Antwort: 
getRowStringBuilder(…)

[crayon-6767a17402e46000595154/]
Antwort: 

getDynamicList(…)

Wie oben bereits erwähnt, ist hierfür eine Klasse mit Propertys notwendig. Diese kann man ganz einfach auch mit den Methoden aus  CreateClass – Klasse erstellen. Dazu weiter unten.
[crayon-6767a17402e4a924122540/]
dann kann man so eine dynamische Liste ganz einfach erstellen:
[crayon-6767a17402e4e090497874/]
 

diese Liste kann man nun z.B. einem Datagrid aus WPF zuordnen:
[crayon-6767a17402e51010013289/]
[crayon-6767a17402e54739273705/]
Das ganze sieht dann so aus:

wem das Datumsformat stört, der kann dem Ereignis AutogeneratingColumn aus dem Datagrid eine Änderung des Datumsformates durchführen:

folgendes soll nun passieren, wenn das Ereignis eintrifft:
[crayon-6767a17402e55215734287/]
Nun sieht das ganze so aus:

Um die Assembly Version irgendwo im Programm optisch darzustellen, kann man diese z.B. im Titelbereich des windows anzeigen lassen.

1. in app.xaml.cs folgende Eigenschaft hinzufügen:
[crayon-6767a17403181645983086/]
2. Der XAML Code zum binden sieht dann so aus
[crayon-6767a17403189373753181/]
 

Hat man den Fall, dass man an eine Methode unendlich viele Parameter übergeben möchte oder die Anzahl vielleicht unbekannt ist, so bietet C# die Möglichkeit über params und ein Array unendlich viele Parameter zu hinterlegen. Ein Beispiel:
[crayon-6767a1740331f579898742/]
Zu beachten ist, dass der Typ unbedingt ein array [] sein muss.

Liest man die Url aus dem HttpListenerContext, die Umlaute wie äöü enthält, so sieht das ungefähr so aus:

aus süß wird s%FC%df.

Abhilfe schaft da die Klasse HttpUtility:
[crayon-6767a174034c4252353619/]
möchte man zurück encodieren macht man einfach :
[crayon-6767a174034c8065814832/]
 

Stack und Heap sind Teil des Arbeitsspeichers, die zu mindestens unter C# vom Kompiler automatisch verwaltet wird.

Beim Stack (dt. Stapel)  werden die Daten quasi aufeinander gelegt. Wenn Speicher freigegeben werden kann, so wird dies auch von oben heraus getan (LIFO Prinzip). Durch dieses Prinzip ist der Stack sehr schnell in seiner Arbeitsweise. Verlässt der Programmcode die geschwungene Klammer { }, werden sämtliche innerhalb angelegte Variablen aus dem Stack entfernt. Obwohl der Speicher sehr gering ist, wächst und schrumpft er während des Programmablaufs.

Der Heap ist nicht so strukturiert wie der Stack, dort liegen die Daten quasi durcheinander und werden vom Stack aus per Zeiger gefunden. Deswegen ist der Heap auch deutlich langsamer in seiner Arbeitsweise.

Was in den Stack und was in den Heap gelangt, bestimmen unter anderem die Datentypen. Weiter beinhaltet der Stack auch die Zeiger der Variablen auf den Heap.

Stack – Wertetypen:

• Alle numerischen Datentypen
• Boolean, Char und Date
• Alle Strukturen, auch wenn ihre Member Verweistypen sind
• Enumerationen, da der zugrunde liegende Typ immer SByte, Short, Integer, Long, Byte, UShort, UInteger oder ULong ist

Heap – Referenztypen, Verweistypen:

• String
• Alle Arrays, auch wenn ihre Elemente Wertetypen sind
• Klassentypen, z.B. Form
• Delegaten
• reine Objekte

Das Verschieben der Daten vom Stack (Wertetyp) zu Heap (Referenztyp) bezeichnet man als boxing 
[crayon-6767a17403669202791251/]
und vom Heap zu Stack als unboxing
[crayon-6767a1740366c352938853/]
 

Auch beim casten können die Daten vom Heap zum Stack geschoben werden:
[crayon-6767a1740366e919868309/]
 

Quelle:

Understanding Boxing and Unboxing