Search results matching tag '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 ;-)