Ich habe hier ein Alert auf meine Work Items und Tasks sowie wenn jemand bestimmte Dateien eincheckt. Möglich sind aber auch noch Meldungen über Builds.
Mit einem Klick auf “New Alert” findet ihr Vorlagen für die verschiedenen Alert-Arten sowie einige vordefinierten Templates.
Wenn ihr eine Vorlage auswählt, seid ihr automatisch als Empfänger vorbelegt. Ihr könnt allerdings auch mehrere Benutzer informieren lassen. Der Name dient ledeglich zur Organisation im Alert Explorer, den Betreff oder den Inhalt der Emails kann man leider nicht weiter beeinflussen. Dies wäre durchaus praktisch um in Outlook spezielle Regeln greifen zu lassen.
Unterhalt der “Alert Definition” werden die gewünschten Filterkreterien angegeben, hier mal ein Beispiel um mich über alle Änderungen an meinen Workpackages / Tasks / Bugs / etc. informieren zu lassen, die nicht ich gemacht habe.

Wer über Änderungen an Dateien informiert werden will, hat über den Source Control Explorer zusätzlich die Möglichkeit mit einem Rechtsklick auf die gewünschte Datei oder Ordner einen Alert zu erstellen. Hier bei wird nur eine Datei in die Alert Definition hinzugefügt. Markiert man mehrere Dateien im SCE, so bleibt der Punkt disabled. Allerdings kann man die Defintition logisch mit OR verknüpfen und so mehrer Dateien mit einer Defintition traken.

Meiner Meinung nach ein großartiges Feature. Nicht selten kommt es vor, dass Workpackages angelegt oder geändert werden, ich dies aber erst spät mitbekomme. Oder aber ich kann verfolgen, ob die Kollegen in den getrakten Dateien auch nur die Zeilen ändern, die sie ändern dürfen

using System;
using System.IO;
using System.Text;

namespace Utilities.IO
{

	/// <summary>
	/// 	A simple class derived from StringWriter, but which allows
	/// 	the user to select which Encoding is used. This is most
	/// 	likely to be used with XmlTextWriter, which uses the Encoding
	/// 	property to determine which encoding to specify in the XML.
	/// </summary>
	public class StringWriterWithEncoding : StringWriter
	{
		private Encoding _encoding;

		/// <summary>
		/// 	Initializes a new instance of the StringWriterWithEncoding class
		/// 	with the specified encoding.
		/// </summary>
		/// <param name = "encoding">The encoding to report.</param>
		public StringWriterWithEncoding(Encoding encoding)
			: base()
		{
			this._encoding = encoding;
		}

		/// <summary>
		/// 	Initializes a new instance of the StringWriter class with the
		/// 	specified format control and encoding.
		/// </summary>
		/// <param name = "encoding">The encoding to report.</param>
		/// <param name = "formatProvider">An IFormatProvider object that controls formatting.</param>
		public StringWriterWithEncoding(Encoding encoding, IFormatProvider formatProvider)
			: base(formatProvider)
		{
			this._encoding = encoding;
		}

		/// <summary>
		/// 	Initializes a new instance of the StringWriter class that writes to the
		/// 	specified StringBuilder, and reports the specified encoding.
		/// </summary>
		/// <param name = "encoding">The encoding to report.</param>
		/// <param name = "sb">The StringBuilder to write to. </param>
		public StringWriterWithEncoding(Encoding encoding, StringBuilder sb)
			: base(sb)
		{
			this._encoding = encoding;
		}

		/// <summary>
		/// 	Initializes a new instance of the StringWriter class that writes to the specified
		/// 	StringBuilder, has the specified format provider, and reports the specified encoding.
		/// </summary>
		/// <param name = "encoding">The encoding to report.</param>
		/// <param name = "sb">The StringBuilder to write to. </param>
		/// <param name = "formatProvider">An IFormatProvider object that controls formatting.</param>
		public StringWriterWithEncoding(Encoding encoding, StringBuilder sb, IFormatProvider formatProvider)
			: base(sb, formatProvider)
		{
			this._encoding = encoding;
		}

		/// <summary>
		/// 	Gets the Encoding in which the output is written.
		/// </summary>
		public override Encoding Encoding
		{
			get { return this._encoding; }
		}
	}
}

Update:
Habe die Klasse mal um Kommentare erweitert.

Die erste Hürde, welche es zu nehmen gilt, ist es, dass ContextMenü auch bei einem Links-Klick zu öffnen. Man kann zwar eine entsprechende Methode nutzen, jedoch gibt es damit Probleme. Daher sollte man hier Reflection nutzen:

// constructor..
this._trayIcon.MouseDown += this.TrayIconMouseDown;

private void TrayIconMouseDown(object sender, MouseEventArgs e)
{
	if (e.Button == MouseButtons.Left)
	{
		MethodInfo mi = typeof (NotifyIcon).GetMethod("ShowContextMenu", BindingFlags.Instance | BindingFlags.NonPublic);
		mi.Invoke(this._trayIcon, null);
	}
}

Nun öffnet sich schon mal das Kontextmenü auch beim Linksklick. Und hier kann man ansetzen, um das Menü entweder zu manipulieren oder zu ersetzen. Ich selbst habe mir einfach zwei Objekte vorbereitet, welche ich je nach Mausklick austausche:

private void TrayIconMouseDown(object sender, MouseEventArgs e)
{
	if (e.Button == MouseButtons.Left)
	{
		this._trayIcon.ContextMenu = this._leftClickMenu;
		MethodInfo mi = typeof (NotifyIcon).GetMethod("ShowContextMenu", BindingFlags.Instance | BindingFlags.NonPublic);
		mi.Invoke(this._trayIcon, null);
	}
	else if (e.Button == MouseButtons.Right)
	{
		this._trayIcon.ContextMenu = this._rightClickMenu;
		MethodInfo mi = typeof(NotifyIcon).GetMethod("ShowContextMenu", BindingFlags.Instance | BindingFlags.NonPublic);
		mi.Invoke(this._trayIcon, null);
	}
}

Beim Testen ist mir aufgefallen, dass es mehrere Events gibt, an die man sich hängen könnte, etwa “MouseUp”, “MouseClick” usw. Beim Testen hat bei mir allerdings nur “MouseDown” korrekt funktioniert, bei den anderen hatte ich das Problem, dass zum Teil das Menü erst angezeigt wurde und dann der Eventhandler durchlaufen wurde (ich glaube sogar immer, wenn ich mit der linken Maustaste geklickt habe). Erklären konnte ich es mir allerdings nicht.

Um meinen Ansatz zu verstehen, muss man wissen, was eine asymmetrische Verschlüsselung funktioniert. Während bei einer symmetrischen Verschlüsselung mit einem Passwort sowohl ver- als auch entschlüsselt wird, gibt es bei der asymmetrischen Verschlüsselung zwei Schlüssel. Den Private und den Public Key. Während der Private und der Public Key verschlüsseln können, ist nur der Private Key in der Lage wieder zu entschlüsseln. Will man hingegen wissen, ob eine Nachricht wirklich vom Besitzer des Private Keys kommt, spricht man von Signierung. Signieren kann nur der Besitzer des Privaten Schlüssels, während jeder Public Key Besitzer dies verifizieren kann.

Dieses Verhalten kann man ausnutzen, der Hersteller der Software ist im Besitz des Private Keys und signiert Dateien, welche von der Software, welche den Public Key kennt, verifiziert. Sollte die Signatur nicht gültig sein, verweigert die Software ihren Dienst. Sollte jemand den Inhalt der Datei manipulieren, so muss sie wieder mit dem Private Key neu signiert werden.

Ich habe mir daher eine kleine, aber feine Klasse erstellt, welche entweder ein XML-Dokument oder eine Klasse, welche per XmlSerializer serialisierbar ist, signieren kann. So kann man theoretisch jede Information in eine XML-Lizenz-Datei hinterlegen, etwa wie lange die Lizenz gültig ist. Die nötigen Klassen befinden sich alle im .NET-Framework ab Version 2.0. Der Code ist zum Teil aus der MSDN (siehe Links am Ende des Beitrages).

Diese Möglichkeit bietet keinen absoluten Schutz. Leute könnten mit Programmen wie dotPeek an den SourceCode gelangen und die Prüfung ausbauen. Mit einem Obfuscator kann dies erschwert werden. Zudem dürft ihr niemals den privaten Schlüssel herausgeben, da dieser sowohl signieren als auch einen Public Key erstellen kann.

Beispielapplikation:

Hier findet ihr eine kleine Beispielanwendung. Die Form ist sehr trivial, erstellt erst die Keys, dann die Dummy-Klasse, signieren und zum Schluss validieren.

Links:

How to: Sign XML Documents with Digital Signatures
How to: Verify the Digital Signatures of XML Documents
Beispielanwendung

Wer Text an Methoden / Klassen weitergeben will, die mit Streams arbeiten, sollte dies nicht umständlich über den MemoryStream lösen, sondern sich lieber mal die beiden Klassen StringReader und StringWriter anschauen. Geht deutlich einfacher und man braucht nicht umständlich mit irgendwelchen Encodings / Bytes / Stream-Positionen rumspielen.

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:msxsl="urn:schemas-microsoft-com:xslt" exclude-result-prefixes="msxsl"
>
    <xsl:output method="xml" indent="yes"/>
    <xsl:template match="@* | node()">
        <xsl:copy>
            <xsl:apply-templates select="@* | node()"/>
        </xsl:copy>
    </xsl:template>
</xsl:stylesheet>

Einfach alle Nodes und Attribute kopieren, also nichts wildes. Dennoch wurde aus:

<xs:element name="comment" type="xs:string" minOccurs="0" />

folgendes:

<xs:element name="comment" type="xs:string" minOccurs="0"></xs:element>

Das Schema ist noch valide und funktioniert tadellos, nur sieht es nicht wirklich schön aus. Nachdem ich im Netz nach einen bestimmten Parameter im C#-Code und ähnliches gesucht hatte, wurde ich doch noch fündig. Das .NET-Framework bietet zwei verschiedene Methoden zur Transformation.
XslTransform und XslCompiledTransform. Der Kommentar in der MSDN sagt eigentlich alles:

Die XslCompiledTransform-Klasse ist ein XSLT-Prozessor, der die XSLT 1.0 Syntax unterstützt. Dies ist eine neue Implementierung, die im Vergleich zur veralteten XslTransform-Klasse die Leistung verbessert. Die Struktur der XslCompiledTransform-Klasse ist der XslTransform-Klasse sehr ähnlich.

Nebenbei werden auch noch das ShortEndTag unterstützt, womit mein Problem gelöst wäre. Der Vollständigkeit halber sollte noch auf diesen Blogeintrag hingewiesen werden: XslCompiledTransform Slower than XslTransform?, denn auch noch die veraltete XslTransform-Klasse scheint noch ihre Daseinsberechtigung zu haben.

<root>
  <node1>Content</node1>
  <node2>Content</node2>
  <node3>Content</node3>
  <node4>Content</node4>
</root>

Ich wollte nur die “node1″ – Node behalten, sprich alle anderen entfernen. Daher mein erster Ansatz:

XmlDocument xmlDocument = new XmlDocument();
xmlDocument.LoadXml("<root><node1>Content</node1><node2>Content</node2><node3>Content</node3><node4>Content</node4></root>");
XPathNavigator navigator = xmlDocument.CreateNavigator();

string[] nodesToRemove = new[] {"//node2", "//node3", "//node4"};

foreach (var nodeName in nodesToRemove)
{
	XPathNavigator node = navigator.SelectSingleNode(nodeName);
	if (node != null)
	{
		node.DeleteSelf();
	}
}

Console.WriteLine(xmlDocument.OuterXml);

Funktioniert und gut.

Nun wollte ich den Ansatz umdrehen, und alle Nodes entfernen, die nicht den Namen “node1″ haben.

XmlDocument xmlDocument = new XmlDocument();
xmlDocument.LoadXml("<root><node1>Content</node1><node2>Content</node2><node3>Content</node3><node4>Content</node4></root>");
XPathNavigator navigator = xmlDocument.CreateNavigator();

string xpath = "/root/node()[name()!='node1']";

XPathNodeIterator nodes = navigator.Select(xpath);
while(nodes.MoveNext())
{
	if(nodes.Current != null)
	{
		nodes.Current.DeleteSelf();
	}
}

Console.WriteLine(xmlDocument.OuterXml);

Leider war das Ergebnis nicht so wie erwartet, obwohl der XPath korrekt ist und die anderen Nodes selektiert. Es wurde nur “node2″ gelöscht, sprich die erste Node, welche mit dem NodeIterator angesprochen wird. Durch das DeleteSelf() liefert MoveNext() automatisch false zurück, wenn es wieder aufgerufen wird. Ähnliche Probleme gibt es etwa auch, wenn in einer foreach()-Schleife der Enumerator geändert wird. Eine mögliche Lösung wäre folgendes:

while(nodes.MoveNext())
{
	if(nodes.Current != null)
	{
		nodes.Current.DeleteSelf();
		nodes = navigator.Select(xpath);
	}
}

Nach dem Löschen wird der XPath einfach noch mal ausgeführt. Meiner Meinung nach keine wirklich schöne Lösung, leider aber die einzige die ich gefunden habe, welche auch funktioniert.

if(!string.IsNullOrEmpty(groupName) && (groupName != "Wert1" || groupName != "Wert2")) { .. }

So eine Code-Stelle war bereits seit 2 1/2 Jahren implementiert. Die if-Bedingung ist immer wahr, sobald groupName gesetzt ist. Die hinteren beiden Bedingungen waren total sinnfrei. Glück im Unglück, in der if-Bedingung wurde zufällig noch mal gefiltert, so dass es hinhaute.
Oder das hier:

public bool MyProperty {
    get {
         bool myProperty = MethodeSowieso(..);
         return myProperty;
    }
}

Warum erst in eine Variable packen?

if(irgendeineTrueFalseBedingung) {
      return true;
}
else {
       return false;
}

Brauch ich ja nicht weiter zu erläutern oder?
Einen kleinen Trieb bekomme ich persönlich beim Klammern. Nehmen wir noch mal das Beispiel von ganz oben, diesmal korrekt aber ohne Klammern:

if(!string.IsNullOrEmpty(groupName) && groupName == "Wert1" || groupName == "Wert2") { .. }

Ich muss erstmal genau Nachdenken, um zu sagen, bei welchen Werten die Bedingung erfüllt ist. Mit zwei Klammern wird dieses Problem sofort gelöst und man kann es als Entwickler nicht mal falsch interpretieren. Ein anderer Kollege klammert auch gern zu viel:

return (variable);

Es stört meiner Meinung nach nur beim Lesen und Sinn erkenne ich hier absolut nicht.

Ich erwarte ja keinen perfekten Code, sicherlich habe ich auch einige Coding Styles an mir, welche andere zum Würgen bringen. Aber ist es zu viel verlangt, zwei mal darüber nachzudenken, was man grade programmiert hat? Und das es auch andere verstehen müssen?

JM2C

		/// <summary>
		/// 	Der Haupteinstiegspunkt für die Anwendung.
		/// </summary>
		[STAThread]
		private static void Main()
		{
			Application.EnableVisualStyles();
			Application.SetCompatibleTextRenderingDefault(false);

			_trayIcon = new NotifyIcon {Icon = Icon.FromHandle(new Bitmap("Gear.png").GetHicon()), Visible = true};
			_trayIcon.Click += TrayIconClick;

			Application.Run();
			_trayIcon.Dispose();
		}

Im Anhang findet ihr eine Beispielsolution. Wichtig ist, dass ihr euch selbst ums Dispose() kümmern müsst, damit etwa das NotifyIcon aus der Taskleiste verschwindet, sobald die Applikation beendet wird. Das Beispiel öffnet beim Klick auf das NotifyIcon eine leere Form. Wird diese geschlossen, wird das ganze Programm beendet.

Download: Beispiel Solution – Start App With Notify Icon

Dabei bringt Visual Studio 2010 eine Reihe von wunderschönen Icons mit.

Jedoch hat der Generator vom Manuel Schmitt einen kleinen Nachteil. Nun gibt es Passwörter / PINs die ich mir nicht merken kann aber auch nicht ändern kann. Sprich ich muss eine Möglichkeit haben, meine vorhandenen Daten in so ein “Zufallsbild” hineinzubekommen. Und daran arbeite ich gerade.
Aktuell kann man sich die Passwortkarte schon generieren, eigene Daten kann man aber noch nicht angeben.

Wenn der Kram fertig ist, gibs ihn hier zum herunterladen!

var dic = new Dictionary<string, string>()
       	{
	{"de", "Deutsch"},
	{"en", "Englisch"}
       	};

Die Werte möchte ich in einer ComboBox haben, die Values als anzuzeigenden Text, die Values soll er mir im Code zurückgeben. Ein Dictionary kann man jedoch nicht direkt als DataSource binden. Da die Lösung selbst bei Google etwas versteckt ist, hier die Lösung:

combobox1.DataSource = new BindingSource(dic, null);
combobox1.DisplayMember = "Value";
combobox1.ValueMember = "Key";

Und schon werden alle Einträge aus dem Dictionary angezeigt

(via Mad Props)

Dazu geht ihr in die Projekteigenschaften und aktiviert unter dem Reiter “Erstellen” den Hacken bei “XML-Dokumentationsdatei”. Nun erstellt er euch aus den Kommentaren bei jedem Build eine solche XML-Datei. Im Editor wird nun auch schon angemeckert, dass die XML-Kommentare fehlen. Um euch nun wirklich zu zwingen, sollte die Solution gar nicht erst gebaut werden, wenn die Kommentare fehlen. Das Fehlen wird als Warning gemeldet, daher sagen wir den Kompiler einfach, er soll Warnings als Fehler behandeln.
Dies geschieht ebenfalls in den Projekteigenschaften unter “Erstellen”. Evtl. kann man das noch verfeinern, indem man nur bestimmte Warnungen als Fehler behandelt, jedoch konnte ich auf die schnelle keine entsprechenden Informationen dazu finden. Ich versuche diese nachzureichen.

Von nun an lässt sich die Solution also nicht mehr kompilieren, sofern nicht überall Kommentare verfasst wurden. Um sich das Leben an dieser Stelle deutlich einfacher zu machen, empfehle ich die kostenlose Visual Studio Erweiterung GhostDoc. Mit ihr könnt ihr per Rechtsklick oder Tastenkombination eure Methode oder Property kommentieren. Dabei werden zum Beispiel schon vorhandene Kommentare aus Interfaces über Überladungen übernommen. Ansonsten erstellt er anhand des Methodennamen eine entsprechende Dokumentation. Man kann sich auch eigene Templates anlegen (habe ich mir sagen lassen). Gebündelt mit einem ordentlichen Programmierstil (bei der Namensgebung) kann man so bestimmt 80% automatisch kommentieren. Eine unglaubliche Zeitersparnis.

C:\Program Files (x86)\WinMerge\WinMergeU.exe /x /e /wl /ub /dl "$(BaseName)" /dr "$(MineName)" "$(Base)" "$(Mine)"

C:\Program Files (x86)\WinMerge\WinMergeU.exe /x /e /wl /ub /dl "$(TheirName)" /dr "$(MineName)" "$(Theirs)" "$(Mine)" "$(Merged)"

Den Merge-Befehl (der zweite) habe ich noch nicht getestet. Wichtig ist, dass die Anführungszeichen setzt. Sonst gibt es Probleme bei Leerzeichen und WinMerge will irgendwelche Verzeichnisse anstatt Dateien öffnen.

List<int> _list = new List<int>();
_list.Add(1);
_list.Add(2);
_list.Add(3);
_list.Add(4);

for(int i = 1; i <= 3; i++) {
   int x = _list[i];
   _list.Remove(x);
}

Mein Code war natürlich nicht mit Integerwerten. Ich musste noch ein paar andere Sachen machen, daher war ein RemoveRange() nicht möglich.
Nun wer findet den Fehler?

Ich liste es einfach mal auf:

Durchlauf: 1 - Lösche Element 1 - Rest 2
Durchlauf: 2 - Lösche Element 2 - Rest 1
Durchlauf: 3 - Lösche Element 3 - Rest 0

Beim letzten Durchlauf wird er immer Probleme kriegen. Das Element gibt es nicht mehr. Durch Remove() rücken die Elemente in der Indizierung nach.
Es müsste also heißen:

Durchlauf: 1 - Lösche Element 1 - Rest 2
Durchlauf: 2 - Lösche Element 1 - Rest 1
Durchlauf: 3 - Lösche Element 1 - Rest 0

oder in C#-Code:

for(int i = 1; i <= 3; i++) {
   int x = _list[1];
   _list.Remove(x);
}

Vor allem wenn man in den Debugger schaut, kamen da merkwürdige Werte raus.
Ich sehe, dass die Methode “DeleteEntries()” mit dem Count-Parameter 2 aufgerufen wird, oben zeigt mir der Debugger aber 1 an. Liegt daran, dass in der Liste bereits ein Element entfernt wurde. Somit ist also, wenn man es genau nimmt, beides richtig.

if(basename($_SERVER["SCRIPT_FILENAME"]) == basename(__FILE__)) {
	header ("HTTP/1.1 404 Not Found");
	exit;
}

Man kann alternativ auf “HTTP/1.1 403 Forbidden” senden, so wird dem Benutzer aber gleich vorgegaukelt, dass die Datei gar nicht existent sei.
In andere Scripte kann man die Datei dennoch ganz normal importieren, etwa per require().

Die alte Schreibweise

Die Schreibweise unter C#3.0 mit Überladung wäre also in etwa so:

    public class Program
    {
        static void Main(string[] args)
        {

            AddValues("Ich bin ein", "String");
            Console.WriteLine(_value);

            AddValues("Ich bin ein", "String", true);

            Console.ReadLine();
        }

        public static string _value;

        public static void AddValues(string value1, string value2)
        {
            AddValues(value1, value2, false);
        }
        public static void AddValues(string value1, string value2, bool output)
        {
            _value = string.Format("{0} {1}", value1, value2);
            if(output)
            {
                Console.WriteLine(_value);
            }
        }
    }

Wenn wir nun das Projekt ausführen erhalten wir folgende Ausgabe.

Ich bin ein String
Ich bin ein String

Die erste Ausgabe erfolgt manuell, die zweite direkt in der Methode, wie gewünscht.

C#4.0 mit Default Values

Unter C#4.0 mit Default Values kann man die ganze Sache nun vereinfachen:

public static void AddValues(string value1, string value2, bool output = false)
{
    _value = string.Format("{0} {1}", value1, value2);
    if(output)
    {
        Console.WriteLine(_value);
    }
}

Die Ausgabe ist identisch. Die erste Zeile wird manuell ausgegeben, die zweite über den Methodenaufruf. Das macht die Sache einfach, spart Code, macht ihn leserlicher. Man findet sicherlich noch weitere Vorteile.

Das Problem erkennen

Kommen wir nun zu den Problemen. Bevor ich die erläutern kann, muss man wissen, wie C# die Default Values behandelt. Wenn man sich die Anwendung per Reflector ansieht, sieht man folgenden Code (in der C#-Ansicht):

private static void AddValues(string value1, string value2, [Optional, DefaultParameterValue(false)] bool output);

Die Zeile spricht für sich. Der Standardwert lautet “false”. Nun erstellen wir ein neues Projekt (“TestApp”) und referenzieren auf unsere Methode mit dem Default Value:

namespace TestApp
{
    class Program
    {
        static void Main(string[] args)
        {
            DefaultValues.Program.AddValues("Ich bin ein", "String");
            Console.WriteLine(DefaultValues.Program._value);

            Console.ReadLine();
        }
    }
}

Ausgegben wird eine Zeile, wie erwartet, durch die manuelle Ausgabe. Nun sehen wir uns die zweite Exe-Datei mal im Reflector an:

Program.AddValues("Ich bin ein", "String", false);

Auf einmal sind drei Parameter vorhanden, obwohl wir nur zwei im Sourcecode angegeben haben. Der Compiler setzt automatisch den dritten Parameter mit dem Standardwert, in dem Fall false.
Nun ändern wir die AddValues()-Methode, die Ausgabe soll standardmäßig sofort in der Methode erfolgen, zudem ändern wir den String etwas:

public static void AddValues(string value1, string value2, bool output = true)
{
    _value = string.Format("Zusammengesetzt: {0} {1}", value1, value2);
    if (output)
    {
        Console.WriteLine(_value);
    }
}

Nun kompilier ich nur das Projekt “DefaultValues” und kopiere die DefaultValues.exe in das Bin-Verzeichnis der TestApp. Wenn ich nun die TestApp.exe starte erhalte ich folgende Ausgabe:

Zusammengesetzt: Ich bin ein String

Allerdings haben wir den Standardwert für die Ausgabe auf true gesetzt, daher müsste die Ausgabe doppelt erscheinen, einmal direkt über den Methodenaufruf und einmal durch die manuelle Ausgabe.

Problem beheben

Dieses Problem resultiert daher, dass der Standardwert nicht “on-the-fly” aus der DefaultValue.exe geholt wird, sondern vom Compiler in der TestApp.exe gesetzt wurde.
Die Methode aus der DefaultValues.exe wird also immer noch mit “AddValues(“Ich bin ein”, “String”, false);” aufgerufen. Und so lange wir das TestApp-Projekt nicht neu kompilieren, wird sich an der Ausgabe nichts ändern.

Fazit

Default Values sind eine nette Sache, um sich Überladungen zu sparen, den Code leserlicher zu machen und dem Programmierer das Leben leichter. Aber eigentlich gibt es keine Default Value, der Compiler setzt einfach nur die Werte, die man vorher manuell gesetzt hat. Wenn man diesen Aspekt nicht vergisst, können DefaultValues eine schöne Sache sein, ansonsten sucht man sich wahrscheinlich dumm und dämlich, bis man den Fehler gefunden hat.

Vielen Dank hier noch mal an Oliver Sturm, welcher die Problematik auf der Basta kurz aber verständlich erklärt hat.

Beispielsolution: DefaultValues.zip

(Wenn Interesse besteht, lade ich mal eine Beispielsolution hoch).

Die GUI ist nicht mehr ganz so aktuell. Aktuell bin ich mir noch nicht so sicher, wie ich die Daten speicher, momentan tendiere ich dazu, die Daten als XML-Datei auf der Platte zu speichern.