Grundsätzlich ist fraglich, ob du Plain-Text per Regex.Replace (statt string.Replace) machen solltest...außer dein "Abschnitt der Datei" ist nur ein Platzhalter für einen tatsächlichen Regulären Ausdruck.

Ich persönlich würde einen Blick auf den Regex.Replace Overload mit MatchEvaluator werfen.

Wenn dir Open Source (bzw. kostenlos) lieber ist, kannst du auch einen Blick auf GraphX bzw. Graph# werfen.

Es gibt zu den generischen ICollection<T> und IEnumerable<T> (in System.Collections.Generic) auch noch nicht-generische ICollection und IEnumerable (in System.Collections), die jeweils von den generischen Varianten unterstützt/implementiert werden. Bau die Prüfung einfach auf die um, wenns dir wirklich nur ums erkennen geht.

Eventuell möchtest du dich mal mehr mit den Grundlagen von Git beschäftigen, denn einerseits sind das einfache Aktionen und andererseits hat das überhaupt nichts mit "Repo löschen und neu Clonen" zu tun.
Versuchs mal mit http://think-like-a-git.net/ und https://try.github.com um zumindest das nötigste zu bekommen.

Ansonsten, git reset --hard HEAD gefolgt von git pull - vorausgesetzt, du bist tatsächlich auf deinem Branch (was nichts mit deinen Befehlen zu tun hat, sondern vorher schon wo schief gelaufen ist).

Wenn die Datei beim Aufruf von File.OpenWrite schon existiert, wird sie nicht geleert. Das heißt, am Ende bleibt möglicherweise Müll aus der alten Zip zurück, wenn die neue kleiner ist (denn bei einer Zip steht die Struktur, Dateinamen usw. am Ende der Datei).
Versuchs mal mit File.Open(Filepath, FileMode.Create) - damit wird die Datei entweder neu angelegt (wenn sie noch nicht existiert) oder auf 0 bytes truncated (wenn sie existiert). File.OpenWrite benutzt intern nämlich nur FileMode.OpenOrCreate, womit die Größe der Datei initial erhalten bleibt.

Grid.IsSharedSizeScope sollte eigentlich das sein, was du willst - es muss halt weit genug oben im Tree definiert sein, da es auf alle untergeordneten Grid Columns wirkt (die dieselbe SharedSizeGroup haben).

Und da es scheinbar recht unbekannt ist, man kann mit der JsonReaderWriterFactory JSON nach XML (und wieder zurück) transformieren, wenn man ohne Newtonsoft.Json auskommen möchte. Funktioniert so auch in Kombination mit dem XmlSerializer, falls den heutzutage noch jemand kennt 😃

Die (aufwändige) Alternative wäre, das Fenster komplett selber zu zeichnen. Dann musst du aber auch sämtliche Fenster-Aktionen selber handhaben (Titelleiste, Fenster verschieben/vergrößern, usw) - und das übersteigt vermutlich den Nutzen um ein Vielfaches.
Oder du schnappst dir eine der Control Libraries die es teilweise kostenfrei und kostenpflichtig gibt, die eigene Fensterklassen anbieten (die dann wiederum unter allen Windowsversionen einigermaßen konsistent aussehen).

Selbes gilt natürlich für die Controls selber, wenn sich diese auch maßgeblich unterscheiden.

Bekommst du den Fehler am Server oder am Client?
Ansonsten gäbe es auch noch die <readerQuotas/> innerhalb des <binding/>; aber die äußern sich üblicherweise durch andere Exceptions...

Klingt ein wenig nach Tracing.

Danke Euch für die Antwort, ich möchte jedoch genau diesen Namespace nicht im XElement1 und XElement2 haben.

Das soll nur im Root als Attribut eingebunden werden.

Ist deine Absicht, dass du den Namespace im Code nur zum Root-Element schreiben musst, oder dass am Ende im Xml nur das Root-Element im Namespace ist?

Für ersteres gibt es leider keine Lösung mit XDocument und Co., weil die nunmal auf dem Xml-DOM basiert und der Namespace semantisch an den jeweiligen Stellen erfordert ist.
Wenn du nur letzteres willst, dann ist dein Code so ok wie er ist; aber dann musst du auch mit den "leeren" xmlns Attributen leben.

Ich bin persönlich kein Fan von GUI Tools und Plugins, sondern benutze lieber die Kommandozeile bei Git...aber hast du schonmal versucht, das Projekt extern zu klonen und dann per VS aufzumachen? Wenn der Git-SCC aktiviert ist, bekomme ich dann genauso die Befehle wie Commit, Push usw. angeboten, die man von einem Plugin erwarten würde.

Du musst alle Elemente im selben Namespace anlegen, sonst wird das nix 😃

XNamespace projectNS = "http://www.blablablubb";
XElement root = new XElement(projectNS + "Project");
[...]
XElement xElement1 = new XElement(projectNS + "xElement1");
XElement xElement2 = new XElement(projectNS + "xElement2");

Andernfalls sind die beiden neuen Elemente im Standard-Namespace - und der ist nunmal quasi "kein" Namespace (weshalb du auch die "leeren" xmlns="" bekommst - der XML Writer wechselt dort vom Namespace "http://www.blablablubb" zurück zum Namespace "").

Und alleine deshalb, weil du am Root-Element ein xmlns Attribut hast, wird das Root-Element selbst nicht inklusive Präfix dargestellt. Das ist aber alles nur Darstellungssache; ändert aber an der Semantik nix.
Dein jetziges Root-Element heißt "Project" und ist im Namespace "http://www.blablablubb"; egal ob dort jetzt <Project xmlns="http://www.blablablubb"> oder <ns:Project xmlns:ns="http://www.blablablubb"> steht.

Wenns XML ist, würde ich es auch als XML behandeln (XDocument und Co).
Dokument laden/parsen, das entsprechende Element wählen und die beiden Attribute lesen/schreiben.

Wenn die Dateien eingecheckt wurden, bevor es die .gitignore gab, musst du sie erst aus dem Repository löschen - nur untracked files werden ignoriert.
Und ansonsten: Nein, nicht ohne deine .gitignore zu sehen.

Im Source, nein - und das tut man üblicherweise auch nicht. Wie Coffeebean schon geschrieben hat nutzt man dafür im Normalfall Ressource-Dateien (entweder resx direkt im Studio, XLiff, oder irgendwas anderes wenns denn sein muss) und ändert nur den String, der am Ende im GUI dargestellt wird.
Stichwort TypeConverter, eventuell das DisplayNameAttribute und diverse andere Techniken (je nachdem, ob du WinForms oder WPF benutzt).

Die Frage ist natürlich auch, wo deine Schichten liegen und wie du mit Änderungen umgehen möchtest. Ich habe zum Beispiel noch keine (produktive, nicht-Beispielhafte) MVVM Implementierung gesehen, wo das ViewModel(Property) direkt auf das Model(Property) weiterleitet.

In unseren Applikationen gehen wir beispielsweise sogar so weit, dass Model und ViewModel sich nicht direkt kennen, sondern nur durch eine Konverter-Klasse dazwischen erzeugt werden. Das "Model" in diesem Sinne ist dabei ein WCF Contract und hat so oder so keine direkte Verbindung zu einem Model wie es serverseitig in der Business Logic hin und her geschubst wird.
Damit können wir beispielsweise auch einfach Änderungen verwerfen, indem wir das ViewModel fallen lassen (anstatt das Model wieder zurücksetzen zu müssen).

Und obwohl wir dabei eigentlich um einiges mehr Schichten haben als du im ursprünglichen Post fürchtest (View -> ViewModel -> WCF Contract (Client) -> WCF Contract (Server) -> DTO -> Datenbanktabelle), könnte ich beim besten Willen nicht behaupten, dass wir irgendwo ein Performanceproblem hätten (abgesehen von der WCF Kommunikation, wenn die Verbindung mal lahmt; oder hausgemachten Logikproblemen die ab und an mal wieder anklopfen) - in-process, egal ob wir jetzt vom Client oder vom Server reden, ist das eigentliche Umschaufeln zwischen zwei Schichten kaum nennenswert und scheint auch in einem Performance Trace nur sehr weit unten auf.

Grundsätzlich würde ich dir als Suchbegriff mal das HtmlAgilityPack oder zumindest den SgmlReader empfehlen, womit du die HTML-Seite über die XML-Api (zb. XDocument und Co) verarbeiten kannst anstatt dich mit Stringoperationen durchzuwühlen.
Allerdings solltest du dir auch überlegen, ob der Eigentümer der jeweiligen Webseite damit glücklich ist, wenn du massenhaft alle Bilder runterlädst.

Ich fürchte das wird so nicht funktionieren, wie du dir das vorstellst. Du möchtest quasi:

<TextBox Text="{Binding $PropertyName}"/>

wobei $PropertyName aus RelativeSource={RelativeSource FindAncestor, AncestorType={x:Type UserControl}},Path=DisplayMemberReference gelesen werden soll.

Was du aktuell hast ist aber der Wert von DisplayMemberReference aus dem Ancestor UserControl (und das ist nunmal der String "DisplayName").

Ins Blaue geraten denke ich mal, dass du hier zumindest einen Converter oder eine Attached Property brauchst, wo die Referenz dynamisch aufgelöst wird.
Rein interessehalber würde mich aber auch interessieren, ob es eventuell eine einfachere Möglichkeit gibt.

Das ganze sieht für mich nach WPF aus. Warum definierst du nicht einfach ein Property in deinem ViewModel (davon ausgehend, dass du ein Xaml View hast, wo eine ViewModel Instanz gebunden ist; zb. ala MVVM), was den aktuell sichtbaren Inhalt darstellt (ist seinerseits wieder ein ViewModel, was per DataTemplate ein View zugewiesen hat) und bei Button-Druck einfach umgesetzt wird?
Dazu könntest du dann auch Commands anstatt Click-Handlern einsetzen, und das Xaml Code-behind komplett loswerden.

Das würde ich direkt wieder abgewöhnen 😃

Aber ansonsten fällt mir gerade kein Keyword ein, dass noch neben value sinn macht.

Eventuell this bei Extension-Methoden?

public static void DoSomething(this MyClass @this)
{
    DoSomethingElseWith(@this);
}

Aber selbst das ist schon ein wenig grenzwertig und könnte je nach Sinn der Methode durch einen brauchbarer benannten Parameternamen ersetzt werden.

Ansonsten gäbe es noch Mono.Cecil, womit du das ganze programmatisch machen kannst. Und sofern du die snk hast, kannst dus sogar wieder signierieren lassen.

Wie sinnvoll (und sicher) das ganze nächträglich ist, sei aber mal dahingestellt. Was spricht dagegen, die AssemblyInfo anzupassen?

Alternativ dazu einfach:

lastTenPositions.RemoveAt(0);
lastTenPositions.Add(art);

...denn RemoteAt(0) entfernt das erste Element; ein umsortieren bzw. nach-vorne-schieben ist nicht notwendig.

Dein Denkfehler liegt darin, dass du nach dem RemoveAt(0) immet noch von einer Liste mit 10 Einträgen ausgehst, obwohl nur mehr 9 Einträge drin sind.

Ein Service hat üblicherweise keine Oberfläche, sondern braucht Client-Code in irgendeiner Form dazu. Salopp gesagt ist das WCF Service wie ein Web-Server, und du brauchst einen Client (zb. Browser) der seine Sprache spricht (zb. HTTP) um was rauszubekommen - praktisch hängt das natürlich alles von der Konfiguration des Services ab, welches Encoding, Protokoll, Transport, Sicherheit usw. verwendet wird.

Wenn du keinen eigenen Client dazu hast, kannst du den WCF Test Client versuchen, der bei VS (und glaub auch beim WinSDK) mit dabei ist. Oder du erstellst dein eigenes Testprogramm mit "Add Service Reference" bzw. "Add Reference" auf die Service-Adresse.

Ich würde mal behaupten, das Framework mit dem du die Tests schreibst/ausführst/auswertest ist da eher nebensächlich; das wichtige ist die Art wie man (sinnvolle) Tests schreibt, dass sie einen auch bei der Arbeit und vor allem bei späteren Änderungen/Refactorings unterstützen.

Sowohl Entity Framework als auch zb. NHibernate haben Mapping-Optionen, wo die Tabellenstruktur aus den Klassen abgeleitet wird. Du kannst zwar eingreifen, wenn du möchtest (und zb. Tabellen oder Spalten umbenennen); aber das klingt in seiner unveränderten Form doch sehr nach dem, was du möchtest - abzüglich einiger Konventionen vielleicht.
Der Vorteil (und an anderen Stellen vermutlich auch Nachteil) von einem O/R Mapper wäre auch, dass du nicht auf SQL Statements als String angewiesen bist, sondern direkt auf dem Objektmodell arbeiten kannst. NHibernate bringt beispielsweise auch eine SQL-ähnliche Sprache namens HQL mit, die ähnlich funktioniert.

Abgesehen davon, dass sich hier vermutlich andere Wege anbieten würden (zb. ein O/R Mapper, oder zumindest Statements mit Parametern anstatt die Werte direkt in den String zu friemeln), könntest du trotzdem Linq verwenden.
Zwar nicht so, wie du vermutlich ursprünglich dachtest, aber Expressions gehören auch zum Linq Namespace.

Bei uns hat sich folgende Klasse bewährt, die du vielleicht adaptieren kannst (wenn du wirklich keine andere Alternative nutzen kannst):

using System;
using System.Linq.Expressions;

namespace Utils
{
    public static class PropertyName
    {
        public static string Of<T>(Expression<Func<T, object>> expression)
        {
            if (expression == null)
                return string.Empty;
            return GetPropertyName(expression.Body);
        }

        public static string Of(Expression<Func<object>> expression)
        {
            if (expression == null)
                return string.Empty;
            return GetPropertyName(expression.Body);
        }

        private static string GetPropertyName(Expression body)
        {
            var memberEx = body is UnaryExpression ?
                ((UnaryExpression)body).Operand as MemberExpression :
                body as MemberExpression;

            return memberEx.Member.Name;
        }
    }
}

//usage:
string propertyName = PropertyName.Of<MyClass>(m => m.ThatMember);
Console.WriteLine(propertyName); //prints "ThatMember"

Und man kann sichs vermutlich schon denken, bei High Traffic Code machts sicher Sinn, das Ergebnis irgendwo zwischenzuspeichern - aber ich hoffe mal nicht, dass du mehrere Millionen male pro Sekunde die Property Namen auf die Art abfrägst.

So ziemlich jedes Objekt in PDF ist ein Container und kann Kind-Element enthalten - das gilt auch für die Bookmarks. Damit würde es mich wundern, wenn du nichts entfernen könntest...ist nur eine Frage, obs die jeweilige Library anbietet.

Wir nutzen PDF Clown, weil uns iTextSharp bei vielen Sachen einfach keine entsprechende API angeboten hat; oder gewisse andere Funktionalitäten einfach nicht implementiert waren.
Der Vor- und gleichzeitig auch Nachteil der Library ist, dass sie sehr nah am tatsächlichen PDF-Objektmodell und damit eventuell auch nicht ganz intuitiv zu verwenden ist.
Und um ehrlich zu sein, wir nutzen die Funktionalitäten in erster Linie zum Auslesen von Bookmarks und zum Mergen anderer Bookmark-Trees (im Zuge des Mergen von mehreren PDFs) - aber das Bookmarks Objekt hat eine .Remove Methode (und verhält sich grundsätzlich wie eine Liste), drum würd ich sagen: Einfach ausprobieren, und schaun was passiert.

Die Frage ist eher, warum die Runtime meint, dass dein Code nicht verifiziert werden kann. Eventuell mal das Snippet herzegen?

Morgen!
Der "Name" vom Root-Knoten ist nicht "nachricht", sondern "{http://mynamespace.de/123}nachricht" (der Namespace - bzw. spezifischer die URI gehört da mit dazu).

Dein X-Path "/nachricht" matcht aber nur auf "nachricht" - drum kommt nix raus.
Zumindest mit X-Path 1.0. In X-Path 2.0 gibts die sogenannten Context-Namespaces, mit denen man sowas machen könnte; aber dafür braucht man halt auch die entsprechenden Libraries.

Wenn dir der Namespace bekannt ist, vergib einfach ein Prefix im XSLT, und benutz das:

<xsl:template match="/myns:nachricht" xmlns:myns="http://mynamespace.de/123">
  <xsl:for-each select="myns:ebene1/myns:liste/myns:ebene2/myns:ebene3.1/myns:ebene4.1">
    [...]

Die passenderen Schlüsselwörter sind hier IMO covariance und contravariance.

Könnte aber durchaus an der Eigenheit des TabControls selber liegen; dass es erst dann Bindings durchführt, wenn man konkret auf das Tab wechselt. Ausprobieren kann mans, in dem man die Methode OnCreateHandle überschreibt und einfach einen Breakpoint reinsetzt. Controls auf der Tabpage werden erst instanziert, wenn sie aktiviert werden - führt mitunter auch zu bösen Implikationen wenn man DataBinding nutzt.

Edit: Siehe MSDN - TabControl Class Remarks:

Controls contained in a TabPage are not created until the tab page is shown, and any data bindings in these controls are not activated until the tab page is shown.

Der xsl:param sollte in deinem Template drin sein, nicht global. Globale Parameter kannst du von außen reingeben (zb. Kommandozeile oder XsltArgumentList), während "lokale" über xsl:with-param gesetzt werden.

Vielleicht noch als Info (ohne den Link gelesen zu haben):
Generierte Settings-Klassen sind üblicherweise zwar sealed, aber auch partial. Bei einem ähnlichen Fall initialisiere ich solche (auch Custom Listen) einfach über die OnSettingsLoaded Methode (die aus der ApplicationSettingsBase kommt) in einer eigenen, von mir definierten (erweiternden) partial Settings-Klasse.

SVN Branches sind halt sehr heavy-weight und für sowas eher nicht unbedingt geeignet. Lokal wäre Git sicher eine schöne Alternative (was gegenüber SVN halt auch ein Umdenken erfordert).

Eventuell hilft dir aber die Extension AutoHistory weiter.

Hast du eine Fehlermeldung für uns? Meine Glaskugel meint zu "Ich komm damit nicht durch den Compiler", dass du Probleme mit den Hochkommas hast (die innerhalb eines Strings escaped werden müssen).
Und die gehören eigentlich zu den Grundlagen.

hier zwei Besucher zu implementieren hat ich für nicht angebracht. Die erste der von dir beschriebene Operation eignet sich für einen Besucher, die zweite - wie ich finde - offensichtlich nicht. Klar kann man die beiden Operationen (Suchen und das eigentliche Einfügen) trennen, das kann Sinn machen, aber das Einfügen ist eine Operation auf zwei Knoten und gerade nicht mehr eine Operation auf der Objektstruktur, wie es Voraussetzung für einen Besucher ist.

Wenn ich seine vorhergehenden Posts nicht missverstanden habe, kanns sein dass eine abgeleitete Klasse jeweils ihre eigene .ChildNodes Collection hat (und nix aus einer Basisklasse, was man "einfach so" verwenden könnte). Daher müsste er für jede konkrete Ableitung, die Unterknoten enthalten kann, eigenen Code schreiben (wofür sich der Visitor schön eignet).

Je nachdem, wie er mit der Struktur noch arbeiten möchte, machts natürlich Sinn (oder auch nicht), die beiden Operationen zu trennen/zusammenzufassen, oder auch gar keinen Visitor dafür zu nutzen - aber das ist letztendlich ihm überlassen (weil er ja hoffentlich besser weiß, was seine Applikation noch alles tun soll).

Das Visitor-Pattern bietet sich grade dann an, wenn du unterschiedliche Operationen auf immer dieselben Objekt-Strukturen anwenden willst.

Ich persönlich würde hier 2 Visitor implementieren (gemäß SRP; auch wenns auf den ersten Blick vielleicht wie Kanonen auf Spatzen aussieht):

• einer, der die "Einfügestelle" (oder allgemein, einen Knoten) sucht und diesen am Ende zurückliefert; sowie
• einer, der zwei Knoten bekommt. Zum einen den "Einfügeknoten" (dessen Typ über den Visitor konkret behandelt wird), der aktualisiert werden soll; zum anderen den "Eingefügten Knoten", der dort reingepackt wird (dessen Typ eigentlich egal ist).

Könnte man natürlich auch in einem machen; aber das schöne am Visitor Pattern ist, dass jede Methode für sich konkret einen bestimmten Fall abdeckt und Änderungen auf die Art sehr wahrscheinlich keine anderen Operationen zerstören (wenn man nicht grade drauf vergisst, eine Rekursion loszutreten).

Ist das nicht ein Feature für Web-Projekte, und Web-Projekte (bzw. Web.config) only? Ich versteh seine Frage eher als App.config für normale GUI/Consolenanwendungen - und dort wär mir sowas nicht bekannt/bewusst.

select coalesce(count(*), 0) from tblTmpAlpha where ...

Edit: ups, das Having übersehen. Damit funktionierts natürlich nicht. Es kommt nämlich kein Null zurück, sondern keine Ergebniszeile. Wäre auch komisch gewesen wenn count(...) ein Null liefern würde.

Du könntest mal versuchen, die Atlassian Developer Toolbox zu installieren (ist ein Plug-In, was direkt über die Administration angeboten wird). Damit bekommst du unter anderem auch den REST API Browser, der dir ua. die Parameter zeigt, teilweise sogar Beispiele drin hat und dir auch noch die Möglichkeit gibt, das ganze direkt auszuführen.

Was brauchbar aussieht dürfte das sein:

GET http://jira-dev/rest/greenhopper/1.0/rapid/charts/scopechangeburndownchart?rapidViewId=1&sprintId=5

...zumindest wars unter Jira 5.x noch so; für ein Upgrade meiner Testinstallation auf 6.x hat die Zeit bisher noch nicht gereicht (und produktiv will ich das net unbedingt machen, wenns nicht sein muss). Für 6.x mit Agile hat sich die URL aber vermutlich geändert...

Mein Tipp wäre eher, dass method gleich null ist @Thread-Titel. Oder hast du schonmal irgendwo var foo = new Bar(); geschrieben, wobei foo in der Zeile danach null war? 😃

Nur zur Info, das CoClassAttribute sorgt dafür, dass du new InterfaceXxx() schreiben kannst/darfst. In der Praxis braucht man das aber nur in Zusammenhang mit COM, und selbst dann wirds eher generiert als selber geschrieben.

Aber wie bereits gesagt, nimm lieber die Alternativen, die direkt im Framework verfügbar sind; wenn du nicht grade einen guten Grund hast um trotzdem über COM/PInvoke/sonstwas reinzugehen.

Hilft dir eventuell SelectMany?

(In erster Linie sollte der Server natürlich nicht abschmieren 😗***)){gray}
Eventuell solltest du dir dann andere Technologien ansehen, wo sowas nicht von Bedeutung ist. Möglicherweise einen MSMQ Transport (der über Message Queues arbeitet), oder was anderes ala ServiceBus (kenn ich persönlich nicht, müsste aber auch in der Richtung zuhause sein - falls nicht, einfach ignorieren).