Peter Bucher : Tipps

Paypal Spenden Button in ASP.NET einfügen

Peter Bucher — Thu, 06 Dec 2012 17:59:00 GMT

Ich wollte einen Paypal Spenden Button auf der LightCore Seite einzufügen, doch ein Button mit komplettem Formular-Tag das von Paypal geliefert wird ist schlecht zu nutzen.
In einen Blog fand ich ein Beispiel, wie ein Spenden Button per Link eingefügt werden kann, per GET also.

Zuerst muss ein Button bei Paypal erstellt werden, damit die ID des Buttons verfügbar ist.

Im folgenden Code dann nur noch die ID des Buttons durch die von Paypal ersetzen èt voila.

<a target="_blank" href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=ButtonIDHierErsetzen">Spende an Produkt XYZ</a>

Kurz und schmerzlos, vielleicht kann es jemand gebrauchen.

Office 2010 installiert und Visual Studio 2008 friert ein?

Peter Bucher — Sun, 20 Jun 2010 20:38:00 GMT

Nebenbei habe ich letztens Office 2010 installiert.
Als ich dann wieder einmal Visual Studio 2008 benutzte, blieb die Anwendung im ASPX-Editor komplett hängen.

Es musste der Prozess abgeschossen werden, um VS überhaupt beenden zu können.
Mein Verdacht lag zuerst bei Resharper, was sich dann aber als falsch herausgestellt hat.

Bei mir hat die Lösung mit dem Reparieren von den "Web Authoring Components" geholfen:

http://blogs.msdn.com/b/webdevtools/archive/2010/04/19/upgrade-or-uninstall-of-office-2007-might-cause-vs-2008-web-designer-to-hang.aspx

InternalsVisibleToAttribute und signierte Assemblies: So funktionierts garantiert.

Peter Bucher — Fri, 04 Dec 2009 15:46:00 GMT

Stellt euch vor, ihr habt zwei Assemblies:

MyProject.Core
MyProject.Core.Tests

Im Core-Projekt gibt es Typen, die nicht öffentlich gemacht werden sollten, allerdings für die UnitTests zugänglich sein sollen.
Nun, das ist ein kleines Problem, wenn man das Attribut “InternalsVisibleTo” kennt, mithilfe folgender Dekleration in der AssemblyInfo.cs des MyProject.Core-Projekts kann dies einfach erledigt werden:

[assembly: InternalsVisibleTo("MyProject.Core.Tests”)]

Das macht sogar sehr viel Sinn, denn sonst können Kollisionen und Verwechslungen der Extensionmethods beim Endbenutzer vorkommen.

Soweit, so gut. Die Typen der MyProject.Core-Assembly sind jetzt in der MyProject.Core.Tests-Assembly sichtbar.
Müssen die Projekte jedoch signiert sein, kommt es zu einem grösseren Problem.

In mehreren Blogs sind die nötigen Schritte beschrieben, jedoch werden da wichtige Punkte nicht genannt, die einem zur Verzweiflung treiben können.
Die sind wie folgt:

Alle involvierten Assemblies müssen signiert werden.
Der PublicKey muss vom Projekt bezogen werden, bei dem die Internals sichtbar werden sollen, in unserem Fall also das MyProject.Core.Tests-Projekt.

Nach einer weiteren Suche bin ich schlussendlich auf einem (selbsternannten) Newbie-Blog fündig geworden.
Noch später sties ich dann auf die folgende Anleitung, die eigentlich alles beinhaltet, sodass ich nicht alles im Detail niederschreiben muss, trotzdem die wichtigen Punkte nennen kann und vorallem die Lösung wieder einmal finde:

Also, beachtet die oben stehenden zwei Punkte und haltet euch an folgende Anleitung:

http://statestreetgang.net/post/2008/04/InternalsVisibleToAttribute-and-Strong-Named-Assemblies-Step-by-Step.aspx

Generierung der designer.cs / vb Datei forcieren oder “Der Name ControlXYZ ist im aktuellen Kontext nicht vorhanden

Peter Bucher — Thu, 03 Sep 2009 17:34:00 GMT

Wenn eine ASPX- / ASCX-Datei ausserhalb vom Visual Studio Editor geändert wird, bekommt das der Designer nicht mit.
Das Updaten der <Dateiname>.<Erweiterung>.designer.cs geschieht nicht sehr häufig und nur bei bestimmten Fällen.

So kann es gut sehr gut sein, dass folgende Fehlermeldung beim Kompilieren erscheint:

The name ‘ControlXYZ’ does not exists in the current context

bzw.

Der Name ControlXYZ ist im aktuellen Kontext nicht vorhanden

Um die Neugenerierung der Designer-Datei zu erzwingen, kann die ASPX- / ASCX- Datei im Designer geöffnet werden, oder eine Eigenschaft hinzugefügt / geändert werden.

Wenn das nichts nützt (Danke an Stefan):

Leider funktioniert das aber lange nicht immer. Ich hab das gerade bei größeren Projekten (meist dann, wenn man in VS ein Control kopiert und umbenennt (inkl. Klassenname natürlich) öfter mal. Schon ein paar mal half schlußendlich nur das Löschen der Datei in VS und das erneute Erstellen. Reines Drag&Drop in das VS Projekt hinein half da auch nciht.

Mehr Details zu diesem Verhalten gibt es in folgendem Posting:

Forcing regeneration of the designer.cs file

LINQ: Any, anyone? Range oder Repeat?

Peter Bucher — Tue, 01 Sep 2009 16:10:00 GMT

Mit LINQ sind unzählige Erweiterungsmethoden für IEnumerable<T> hinzugekommen, die auch ausserhalb von LINQ Abfragen sehr nützlich sein können.

Damit ich mir das merke und ihr evt. noch was neues kennenlernt, möchte ich zwei kurz vorstellen:

Enumerable.Any()

Kommt euch Code wie der folgende bekannt vor?

if(addresses.Count > 0) { // … }

oder

if(addresses.Count == 0) { // … }

Das kann jetzt folgendermassen umgeschrieben werden:

if(addresses.Any()) { // … }

und

if(!addresses.Any()) { // … }

Die Implementation der Any()-Methode holt sich den Enumerator der Auflistung und versucht den ersten Eintrag zu holen, wenn das klappt gibt sie true zurück, ansonsten false.

Wenn Any() true zurückliefert, heisst das also, es ist mindestens ein Element vorhanden.

PS: Darüber hinaus gibt es auch noch eine zweite Überladung, der man Funktion einspeisen kann (Anonyme Methode, Lambda Ausdruck, …). Diese bestimmt dann, ob es mindestens ein Element hat, bei dem die Funktion true zurückliefert.
Die Funktion nimmt ein Element vom Typ TSource entgegen und gibt einen bool zurück.

Enumerable.Range() und Enumerable.Repeat()

Schon mal Testdaten benötigt, oder eine Liste von Zahlen die dann durcheinandergewürfelt werden?
Das schreibt man im einfachsten Fall dann in etwa so:

List<int> numbers = new List<int>(); for(int i=1; i <= 100; i++) { numbers.Add(i); } // …

Mit Enumerable.Range() geht das viel einfacher:

var numbers = Enumerable.Range(1, 100); // …

Mit LINQ lässt sich ganz einfach eine gemischte Liste von Zahlen erstellen, zwei Zeilen braucht es dazu:

Random random = new Random(); var numbers = Enumerable.Range(1, 100).OrderBy<int, int>(random.Next);

Hier noch ein kleiner Hinweis: Um eine gleichmässige Verteilung einer solchen Liste zu erhalten, sollte ein Algorithmus wie bspw. hier benutzt werden.

An Enumerable.Repeat() hingegen kann im ersten Parameter eine Instanz übergeben werden, oder auch ein einfacher Wertetyp wie bspw. eine Zahl und eine Anzahl, wie häufig dieser Wert wiederholt werden soll.
Schlussendlich bekommt man eine Auflistung zurück, das wars.

Alles var – oder nicht?

Peter Bucher — Tue, 01 Sep 2009 07:37:00 GMT

Am 13. Oktober 2008 haben Golo Roden und ich unter dem Titel Noch Fragen, Roden? Ja, Bucher! angekündigt, jeweils zum ersten eines jeden Monats einen Kommentar zu einem vorab gemeinsam gewählten Thema verfassen zu wollen. Bisher sind in dieser Reihe folgende Kommentare erschienen:

1. August 2009: C# oder VB: Welche Sprache soll ich lernen?
1. Juli 2009: Primärschlüssel: GUID vs Identity
1. Juni 2009: Heißt die Zukunft RIA?
1. Mai 2009: Woran erkennt man einen guten Entwickler?
1. April 2009: Interfaces vs abstrakte Klassen
1. März 2009: Sinn und Zweck von AOP
1. Februar 2009: Die Forderung nach Softwarequalität
1. Januar 2009: SOA vs WOA
1. Dezember 2008: Dynamic Language Runtime: .NET, quo vadis?

Heute, am 1. September 2009, ist es nun wieder so weit, und unser Thema für diesen Monat lautet:

Alles var – oder nicht?

So wohl Golo wie auch ich haben uns unabhängig voneinander im Vorfeld unsere Gedanken gemacht, wie wir diesem Thema gegenüberstehen. Golos Kommentar findet sich zeitgleich in seinem Blog, folgend nun mein Kommentar zu diesem Thema:

Nein, werter Leser, das ist kein Rechtschreibefehler, das ist eine wirklich vwa(h)re Geschichte.
Scherz beiseite, los gehts… ;-)

Einleitung

Mit C# 3.0 kam ein neues Schlüsselwort names var hinzu, nur was hat es damit auf sich?

Es handelt sich dabei weder um ein spät gebundenen noch um einen Variant Typ, wie man ihn bspw. von Scriptsprachen her kennt, sondern um ein Feature das erst die Nutzung von anonymen Typen möglich macht.

Einfach gesagt heisst das, dass der Compiler den Typ auf der linken Seite vom Ausdruck auf der rechten Seite ableitet.
Also sind die Variablen immer stark typisiert und zwar zur Kompilezeit, nicht erst zur Laufzeit.

Was ist der Sinn des ganzen, bzw. wieso wurde dieses Feature integriert?

Im Zuge der Entwicklung von LINQ wurden die anonymen Typen eingefügt um eine Projektion der Daten auf irgendeine Objektstruktur zu ermöglichen, ohne dazu immer wieder neue Datenhaltungsklassen erstellen zu müssen.

Damit ist dann bspw. sowas möglich:

List<string> data = new List<string> { "Patrick:24", "Stefan:16", "Jörg:22" }; var persons = from dataEntry in data let splitted = dataEntry.Split(new[] { ':' }) select new { Name = splitted[0], Age = int.Parse(splitted[1]) }; foreach (var person in persons) { Console.WriteLine("Name: {0}, Age: {1}", person.Name, person.Age); }

Dabei ist der Typ von persons IEnumerable<T> wobei T in Visual Studio als "a” für Anonymous gekennzeichnet wird.
Und dementsprechend ist jeder Eintrag in dieser durchlaufbaren Menge ein anonymer Typ, der im Hintergrund vom Kompiler generiert und bereitgestellt wird.

Die Eigenschaft “Name” ist – wer hätte es gedacht – vom Typ string und “Age” vom Datentyp int.

Wo kann var überall eingesetzt werden?

Das Schlüsselwort kann nur für lokale Variablen genutzt werden, so sind automatisch auch anonyme Typen nur in diesem Bereich nutzbar. D.h. es können auch keine anonymen Typen über Methodengrenzen hinaus übergeben werden.

Wo macht es Sinn var einzusetzen und wann ist ein var mehr zuviel?

Das ist eine spannende Frage und eigentlich der Kernpunkt dieses Streitgespräches.
Hier einfach mal ein paar Beispiele:

private void SetProperties() { var collectionMapping = this.CollectionMapping; if(collectionMapping.Count() > 0) { collectionMapping.Clear(); } } private void SetProperties() { ICollectionMapping collectionMapping = this.CollectionMapping; if(collectionMapping.Count() > 0) { collectionMapping.Clear(); } }

public static void RegisterType() { var objectToXElement = BuildObjectToXElementFunc<TEntity>(); var xElementToObject = BuildXElementToObjectFunc<TEntity>(); RegisterType(objectToXElement, xElementToObject); } public static void RegisterType() { Func<TEntity, XElement> objectToXElement = BuildObjectToXElementFunc<TEntity>(); Func<XElement, TEntity> xElementToObject = BuildXElementToObjectFunc<TEntity>(); RegisterType(objectToXElement, xElementToObject); }

oder sowas:

var wtf = GetPattern();

Pattern pattern = GetPattern();

In der ersten Methode wird var benutzt und in der folgenden dann nicht mehr.
Ich habe die Beispiele extra so gewählt, denn wenn in diesen Methoden var benutzt wird, sieht man auf den ersten Blick (ohne die Maus zu benutzen, oder einen verrenkten Shortcut) nicht, um was für einen Typen es sich hier handelt.

Und das ist natürlich ein sehr wichtiger Aspekt.
Denn was nützt mir das weniger schreiben und weniger Code, wenn ich beim lesen – was übrigens vom Zeitaufwand deutlich mehr ist als das Schreiben – nicht mehr auf den ersten Blick erkennen kann, was für Typen das sind.

Man sollte das Schlüsselwort im Regelfall wirklich nur einsetzen um die anonymen Typen benutzen zu können.

Ausnahme wenn es sich um eine lange Typdefinition handelt _und_ initialisiert wird

Ich für meinen Teil halte es so, das ich es eben dann benutze und zusätzlich auch noch in Fällen bei denen die Initialisierung (nicht Zuweisung) rechts daneben steht.

Und das auch nur wenn es sich um eine lange und komplexere Typbezeichnung handelt, das sind dann meistens solche mit generischem Typparameter, Beispiel:

public void Foo() { Dictionary<string, Person> persons = new Dictionary<string, Person> {…} }

public void Foo() { var persons = new Dictionary<string, Person> {…} }

Durch den sprechenden Namen und dadurch das die Initialisierung der Variable und so auch die implizite Zuweisung des Types auf der rechten ist, kann das auch gut gelesen werden und ist praktikabel finde ich.

Diese Anwendung hilft auch Redundanzen zu vermeiden. Wenn man bspw. die Initialisierung änderet ist der Typ auch automatisch angepasst.
Das ist ein netter Nebeneffekt, kann aber auch böse enden, wenn man sich dessen nicht bewusst ist, das Interface gleich ist, aber sich die Methoden / Eigenschaften die später aufgerufen werden, anders verhalten.

Ausnahme wenn es um LINQ Abfragen handelt

Bei LINQ Abfragen benötigt es kein var, wenn keine anonymen Typen genutzt werden.
Allerdings halte ich es auch bei LINQ-Abfragen so, dass ich meistens var benutze.
Denn mit guten Namen und im kleinen Kontext gehalten ist klar und verständlich was rüber kommt. Grösster Vorteil hierbei ist auch die automatische Anpassung des Types.

Dies kommt in diesem Fall sehr zum Vorschein, denn durch Projektion kann sich der Rückgabetyp schnell ändern, obwohl die Eigenschaften bspw. gleich bleiben.

public void Foo() { IEnumerable<Person> persons = from person in list.Persons where person.Age > 20 select person; }

public void Foo() { var persons = from person in list.Persons where person.Age > 20 select person; }

Das wars auch schon mit den Ausnahmen. Alles andere ist in meinen Augen nicht mehr lesbar und auch nicht gerechtfertigt.
Ich finde es schon ein wenig beängstigend, wenn ich im Web (Auch von Microsoft) Beispiele sehen, die Zahlen und Zeichenfolgen in 20, 30 Zeilen nur mit var arbeiten.
Wenn die Variablennamen dann noch schlecht gewählt, gute Nacht.

Was denkt ihr über die Sache und vorallem über meine genannten Ausnahmen?

Shortcut für das kompilieren des aktuell selektierten Projekts erstellen

Peter Bucher — Mon, 06 Jul 2009 18:02:35 GMT

Es gibt den Short-Cut CTRL-SHIFT-B um das die aktuelle Solution zu kompilieren.
Ein Shortcut um das aktuell selektierte Projekt zu kompilieren gibt es standardmässig leider nicht, das lässt sich aber leicht ändern und ist super praktisch.

Tools –> Options –> Keyboard –> Build.BuildSelection auswählen und einen Shortcut vergeben.

Nicht vergessen den Shortcut per “Assign” oder “Zuweisen” auch wirklich zuzuweisen.
Wenn der Shortcut im Menü angezeigt wird, funktioniert er auch. Ein Neustart von Visual Studio ist nicht nötig.

Mehr zu Shortcuts gibts ausserdem in einem älteren Blogpost: Mausfrei für eine Woche, oder: Home, End und Konsorten

SqlServer: User or role already exists in the current database

Peter Bucher — Fri, 03 Jul 2009 17:50:00 GMT

Wenn ein Backup von einer SqlServer-Datenbank zurückgespielt wird kann es sein, das anschliessend für die vorher berechtigten Benutzer das Login fehlschlägt.
Im Sql Management Studio kann unter der Funktion "UserMapping" die Berechtigung im Normalfall wieder zugewiesen werden, jedoch kann es eben in diesem Fall zum Fehler 15023 kommen.

Für mehr Details zu diesem Fehler siehe hier und hier, wie man den Fehler beheben kann findet sich in diesem und diesem Blogpost.

MSDN Webcastserie zur pragmatischen Webarchitektur mit ASP.NET 3.5

Peter Bucher — Thu, 02 Jul 2009 21:00:54 GMT

Auf MSDN ist eine neue Ausgabe vom PWA (Pragmatic Web Architecture) von Patrick A. Lorenz erschienen, das ASP.NET 3.5 fokusiert.

Ich finde das Konzept gut gelungen und die vorherige Ausgabe der Webcast-Serie (Aus dem Jahre 2006) war sehr gut gemacht. Darum empfehlen ich allen die sich für eine pragmatische Architektur mit ASP.NET interessieren, da reinzuschauen.

Zitat:

Grundkonzept von PWA ist eine dem Projekt angepasste, flexibel erweiterbare Architektur für Web-Applikation. Seit über sechs Jahren kommt PWA nicht nur bei der PGK sondern auch vielen anderen Unternehmen erfolgreich zum Einsatz. Bereits 2006 wurde das Konzept mit einer umfangreichen Webcast-Serie, Artikeln und Vorträgen vorgestellt. Mit .NET hat sich auch PWA über zeit verändert. Die neue Webcast-Serie stellt PWA basierend auf ASP.NET 3.5 SP 1 und mit einer neuen Beispielapplikation vor.

Die Webcasts und Quelltexte können direkt von der Firmen-Webseite von Patrick heruntergeladen werden.

Neue MSDN Webcast-Serie zu ASP.NET Architektur (Webcasts und Quelltexte)

Optimierungseinstellung im Reflector, oder: Wie sieht LINQ wirklich aus?

Peter Bucher — Mon, 08 Jun 2009 18:24:00 GMT

Beim dritten Treffen vom .NET Stammtisch Konstanz - Kreuzlingen habe ich einen Vortrag über LINQ gehalten.
Dabei wollte ich zeigen wie aus dem SQL ähnlichen Syntax von LINQ aneinandergereihte Methoden Aufrufe werden und aus den Lambda Ausdrücken jeweils anonyme Methoden.

Das geht über den Reflector auch wunderbar. Kurz vor dem Vortrag habe ich den Fehler begangen und Windows 7 installiert… nicht das Windows 7 der Fehler gewesen wäre, sondern die Neuinstallation.
So hatte ich vieles noch nicht 100% so wie es war und ausserdem war plötzlich die neuste Version vom Reflector installiert.

Als ich während dem Vortrag den Code demonstrieren wollte, bekamen wir natürlich nur wunderschöne Lambda-Ausdrücke zu sehen, keine anonymen Methoden. Ich wusste nicht wieso und hatte keine Zeit das herauszufinden.

Edit:
LINQ war das natürlich nicht, sondern nur Lambda-Ausdrücke.
Jedoch gilt das genau so für LINQ, dort wird die LINQ-Syntax automatisch vom Kompiler in den Erweiterungemethoden-Syntax + Lambda-Ausdrücke umgewandelt.
Natürlich kann auch von Hand der Erweiterungsmethoden-Syntax benutzt werden, bei einer Bedingung oder wirklich komplexen Aufgaben ist das meist angenehmer.

LINQ-Syntax

public Download GetDownloadByFileName(string fileName) { return (from download in this.GetList() where download.FileName == fileName).SingleOrDefault(); }

Erweiterungsmethoden-Syntax

public Download GetDownloadByFileName(string fileName) { return this.GetList().Where(download => download.FileName == fileName); }

.NET 3.5

public Download GetDownloadByFileName(string fileName) { return this.GetList(d => d.FileName == fileName).SingleOrDefault(); }

Eigentlich ist es relativ einfach, man gehe im Menü unter: View –> Options –> Disassembler und stellt bei Optimization .NET 2.0 ein, dann sieht es nämlich so aus:

public Download GetDownloadByFileName(string fileName) { return this.GetList(delegate (Download d) { return d.FileName == fileName; }).SingleOrDefault<Download>(); }

Wird None oder .NET 1.0 eingestellt ist der Code schon fast nicht mehr zu lesen.
Es ist hier gut zu erkennen, was der Kompiler im Hintergrund alles erzeugt damit die oben geschriebene Syntax funktioniert.

public Download GetDownloadByFileName(string fileName) { <>c__DisplayClass1 CS$<>8__locals2; Download CS$1$0000; CS$<>8__locals2 = new <>c__DisplayClass1(); CS$<>8__locals2.fileName = fileName; CS$1$0000 = this.GetList(new Func<Download, bool>(CS$<>8__locals2.<GetDownloadByFileName>b__0)).SingleOrDefault<Download>(); Label_0028: return CS$1$0000; }

Bearbeitung / Korrekturen:
09.06.09 - Das Codesnippet zu .NET 2.0 war natürlich das falsche, jetzt sieht man auch die anonyme Methode.
09.09.09 - LINQ war ja nicht drin, ist jetzt hinzugefügt ;-)

ASP.NET MVC: Daten zur View Masterpage übergeben

Peter Bucher — Fri, 27 Mar 2009 23:03:00 GMT

Ich stand gerade vor der Aufgabe, die UserTimeline eines Twitter Accounts auf einer ASP.NET MVC Masterpage anzuzeigen.
Dabei muss die Masterpage irgendwie an die Daten kommen, die sie anzeigen will.

Eine naive Suche bringt mich mit dem ersten Ergebnis sofort ans Ziel:

http://www.google.com/search?oe=utf8&ie=utf8&source=uds&start=0&hl=de&q=asp.net+mvc+master+%2Bshow+data

=> Passing Data to View Master Pages

Dort stellen sie zwei Möglichkeiten vor.
Bei der ersten wird vorgeschlagen im Konstruktor jedes Controllers die benötigten Daten in das ViewData-Dictionary zu übergeben.
Das wird natürlich mühsam und bei einer Änderung können alle Controller angefasst werden.

Die zweite Möglichkeit schlägt einen abstrakten Basiscontroller vor, in dessen Konstruktor das ViewData-Dictionary gefüllt wirde.
Eine gute Lösung und die Änderung findet an einer Stelle statt.

Alle Controller müssen dann von dem abstrakten Controller erben, dabei wird jedesmal dessen Konstruktor ausgeführt und die Daten übergeben.
Ein solcher Controller könnte bspw. so aussehen:

namespace Netkk.Controllers { public abstract class ApplicationController : Controller { public ApplicationController() { ITwitterRepository repository = new TwitterRepository(); IEnumerable<string> formattedTweets = repository.GetFormattedUserTimeLine( "username", "password", 4); ViewData["userTimeLine"] = formattedTweets; } } }

Und im Masterpage View kann kann über das Dictionary darüber iteriert werden:

<% foreach(string formattedTweet in (IEnumerable<string>)ViewData["userTimeLine"]) { %> <p> <%= formattedTweet %> </p> <% } %>

Ist dagegen etwas auszusetzen oder gibt es eine bessere Lösung?

Schneller finden mit keyboardr.com

Peter Bucher — Sun, 25 Jan 2009 19:55:00 GMT

Albert hat es schon geschrieben und ich versuche es nur auch mal damit :)

http://www.keyboardr.com/ reagiert sofort bei der Eingabe eines Wortes (oder des nächsten) mit der Suche.
Angezeigt werden Ergebnisse von Google, Google Bilder, Wikipedia und Youtube.

Über die Pfeiltasten kann innerhalb der Ergebnisse navigiert werden und per Druck auf die Enter Taste kann ein Ergebnis in einem neuen Fenster geöffnet werden und sie Suche ohne Pause weitergehen.

Bei mir im Moment die Startseite. Mal schauen wie sich das bewährt.

~~ps: Weiss jemand wie man die Suchergebnisse in einem Tab öffnen kann (IE)?~~

Danke für den Tip Albert, über die Tab-Einstellungen im IE gehts natürlich wunderbar.

Konfiguration per configSource-Attribut auslagern

Peter Bucher — Thu, 22 Jan 2009 18:18:00 GMT

Eine web.config- oder app.config-Datei kann mit der Zeit ziemlich gross und unübersichtlich werden.
.NET bietet hierfür aber eine Lösung per configSource-Attribut.

Ein normaler Konfigurationsabschnitt für HttpHandlers sieht so aus:

 […] 
<httpHandlers> 
    <add verb="GET" path="Download.axd" type="Project.Downloads.DownloadHandlerFactory"/> 
</httpHandlers> 
[…]

Wenn dieser Teil ausgelagert werden will, reicht dann diese Notation in der web.config:

<httpHandlers configSource="Configuration\HttpHandler.config" />

Die HttpHandler.config in einem Verzeichnis oberhalb des Roots sieht dann bspw. so aus:

<httpHandlers> 
    <add verb="GET" path="Download.axd" type="Project.Downloads.DownloadHandlerFactory"/> 
</httpHandlers>

Für eigene Konfigurationsabschnitte kann genau gleich vorgegangen werden.
Zusätzlich gibt es da noch die Möglichkeit per restartOnExternalChanges-Attribut das auf false gesetzt ist und innerhalb der <configSections><section …. platziert werden muss, festgelegt werden ob die Applikation neu starten soll wenn die externe Konfigurationsdatei geändert wurde.

Das ist eine gute Möglichkeit per Laufzeit Einstellungen zu wechseln.
Jedoch sollte man abschätzen wie kritisch die Änderungen sind und ob der Zugriff darauf die Applikation in einen undefinierten Zustand bringen könnten.
Um das zu verhindern, müsste ggf. ein Locking-Mechanismus implementiert werden.

Die möglichen Vorteile bei der Nutzung dieser Möglichkeit:

Bessere Übersichtlichkeit
Ermöglicht einfaches Austauschen von Teilen der Konfiguration (Bspw. Developer- und Productivemaschinen haben verschiedene Connectionstrings)
Gibt die Möglichkeit Änderungen während der Laufzeit auszuführen

Unbekanntes Visual Studio Feature: Gleiche Datei doppelt in der Editoransicht darstellen

Peter Bucher — Thu, 22 Jan 2009 17:49:18 GMT

Visual Studio überrascht immer wieder aufs neue, so ist es mir heute ergangen.
Wenn innerhalb einer Datei zwei Stellen verglichen werden müssen, ist es mühsam immer von oben nach unten und vice versa zu scrollen.

Um das zu vermeiden gibt es einen einfachen Trick, oberhalb der vertikalen Scrolleiste hat es ein kleines Viereck das mit der Maus nach unte gezogen werden kann.

Die Benutzung:

Das Resultat:

Typkonvertierung vereinfacht, oder: .ToOrDefault();

Peter Bucher — Mon, 08 Dec 2008 20:29:00 GMT

*Update

Im Zuge meiner Arbeit an der SessionFacade ging mir das Licht auf, dass wir es im Optimalfall mit relativ wenigen Session-Variablen zu tun haben und über eine SessionFacade auch einen einfachen typisierten Zugriff gewähren können.
Zudem finden wir in der Session im Normalfall nur geboxte Typen, die mit einem einfachen Cast zu ihrem Urprungstyp gewandelt werden können.
Da die .To-Methoden nur für das Parsen vom Typ String in einen anderen Typen gedacht ist, bringt es nichts bspw. ein geboxter int zu einem String zu wandeln um diesen nochmals zu parsen, wenn ein Cast reicht.

Zudem ist die Angabe von "object" als Zieltyp für eine Extensionmethode nicht sehr gut gewählt, da sie dann bei allen Typen erscheint. Vorallem dann natürlich nicht, wenn es relativ unsinnig ist.

Im Zuge dieser Erkenntnis habe ich den Zieltyp auf "string" geändert.
Zusätzlich gibt es auch noch die Anforderung bei einem nicht erfolgreifen Parsing auf einen anderen Typen, einen Startwert zu setzen, der vom Standardwert des Typen abweicht.

Ich habe das Beispiel unten geändert und die Erläuterung plus ein Beispiel für die zweite Überladung mit dem Standardwert hinzugefügt. Viel Spass!

Insbesondere bei der Webentwicklung mit .NET haben wir viel mit Eingaben als Strings zu tun.
Diese müssen dann in int, DateTime, double, Guid, etc... konvertiert werden.

.NET bietet dabei <Type>.Parse()- / <Type>.TryParse()- oder ConvertTo<Type>-Methoden an.

Hierbei gilt die Empfehlung <Type>.TryParse() zu verwenden um auf eine nicht mögliche Konvertierung aufgrund von Nullwerten oder ungültigen Werten zu reagieren.

Die ganze Geschichte gibt aber viel sich immer wiederholende Schreibarbeit, ein Extrembeispiel der Konvertierung eines Strings (Oder null-Literal!) aus einer GET-Parameter Abfrage zu einem int könnte mit <Type>.TryParse() so aussehen:

 

string value = Request.QueryString["index"]; // Kann auch das Literal "null" darstellen 
int typedValue;

if(int.TryParse(value, out typedValue) && typedValue == 4) { 
    lblStatus.Text = string.Format("Wert gültig: {0}", typedValue); 
}

Für eine Konvertierung, die so häufig vorkommt ist das mir - auch aufgrund von anderen Überlegungen - viel zu viel Schreibarbeit.
Ich stelle mir sowas vor:

 

int typedValue = Request.QueryString["index"].ToOrDefault<int>();

if(typedValue == 4) { 
    lblStatus.Text = string.Format("Wert gültig: {0}", typedValue); 
}

Zuerst meine Überlegungen:
Ob eine Konvertierung erfolgreich war, brauche ich nur den Wert zu überprüfen, einen Boolean ob die Konvertierung erfolgreich war, brauche ich nicht.
Bei int reicht mir eine Prüfung auf den Stardardwert 0, bei Guid die Prüfung auf Guid.Empty, bei DateTime entweder DateTime.MinValue.
Sind es boolsche Werte oder kann man / möchte man .MinValue von DateTime nicht benutzen, nimmt man sich Nullable Types zur Hilfe.

Mehr braucht es meines Erachtens nicht um primitive Typen sowie erweiterte Strukturen zu konvertieren und festzustellen was angekommen ist.

Ich habe mir dazu eine Methode geschrieben, die nach Wunsch entweder als Extension Method oder als statische Hilfsmethode in einer Tools-Klasse genutzt werden kann. (Das Original ist hier zu finden)

Die Implementierung:

 

public static partial class Common
{
    /// <summary>
    /// Gibt ein typisiertes Objekt aus einem String zurück.
    /// Falls die Umwandlung nicht erfolgreich ist, wird stattdessen
    /// der Standardwert des Zieltypen zurückgegeben.
    /// </summary>
    /// <typeparam name="T">Zieltyp</typeparam>
    /// <param name="value">Zu typisierenden String</param>
    /// <param name="defaultValue">Standardwert (Wird bei Fehlschlag zurückgegeben)</param>
    /// <returns>Typisiertes Objekt</returns>
    public static T ToOrDefault<T>(this string value, T defaultValue)
    {
      T result = defaultValue;

      if (value == null)
        return result;

      TypeConverter converter = TypeDescriptor.GetConverter(typeof(T));
      if (converter.CanConvertFrom(typeof(string)))
      {
        try
        {
          result = (T)converter.ConvertFrom(value);
        } catch (Exception) {}
      }

      return result;
    }




    /// <summary>
    /// Gibt ein typisiertes Objekt aus einem String zurück.
    /// Falls die Umwandlung nicht erfolgreich ist, wird stattdessen
    /// der Standardwert des Zieltypen zurückgegeben.
    /// </summary>
    /// <typeparam name="T">Zieltyp</typeparam>
    /// <param name="value">Zu typisierenden String</param>
    /// <returns>Typisiertes Objekt</returns>
    public static T ToOrDefault<T>(this string value) {
        return value.ToOrDefault<T>(default(T));
    }
}

Die Nutzung sieht dann bspw. so aus:

 

// Nullable
DateTime? date = Request.QueryString["date"].ToOrDefault<DateTime?>(); 
if(date.HasValue) { 
    <meinObjekt>.Date = date.Value; 
}

// Kein Nullable
Guid guid = Request.Form["userGuid"].ToOrDefault<Guid>(); 
if(guid != Guid.Empty) 
    currentUser = User.Load(guid);
// Standardwert
int width = Request.QueryString["width"].ToOrDefault<int>(1024);
// width == 1024 bei erfolglosem Parsing (Wenn bspw. der Parameter null zurückgibt)
// width == 4 bei erfolgreiem Parsing bei einem Eingangsstring von "4"
// Oder ohne Angabe des Typparameters (Typ wird implizit durch die Angabe des Standardwertes ermittelt)
int height = Request.QueryString["height"].ToOrDefault(768);

Diese Methode ist dafür gedacht um Strings oder geboxte Strings (Bspw. ein object das von Session[<Index>] zurückkommt aber ein String enhält in die typisierte Version zu konvertieren.
Double zu int oder eigene Objekte funktionieren nicht, dafür gibt es Casts oder man schreibt sich eigene Typekonverter dafür.
Bei normalen Typen (int, string, double, ...) wird bei der Eingabe von null oder ungültigen Strings jeweils der .NET-Standardwert (int = 0, Guid = Guid.Empty, ...) geliefert, bei der Verwendung von Nullable Types kann dann eine Prüfung gegen null benutzt werden.

Was denkt ihr?
Benutzt die Kommentarfunktion!

Bearbeitung / Korrekturen:
17.12.08 - Möglichkeit zur Angabe eines Standardwertes hinzugefügt (Inspiriert durch Golo Roden)
19.12.08 - Die .To-Methode vereinfacht (Danke an Golo Roden)
19.12.08 - Die Methode von "To()" nach "ToOrDefault()" umbenannt.