ppedv Blog

[Stefan Döring] Speed Test fr die Groen 4

Stefan Döring — Thu, 14 Aug 2008 14:18:18 GMT

Einen sehr interessanten Geschwindigkeitstest für die Verarbeitung von Javascript (Stichwort AJAX) gibt es unter: http://celtickane.com/webdesign/jsspeed2007.php Die dort angegebenen Ausführungszeiten für die versch. Browser stimmen mit meinen Tests allerdings eher mäßig überein. Am besten selbst einmal testen, welche Werte sich für die eigene Installation ergeben. Meine Werte für die "4 Großen" sind im Übrigen (gerundet auf volle 50ms): Internet Explorer 7.0.6001.18000 (keine Addons) ~ 1000ms Firefox 3.01 (mit div. Addons) ~ 500ms Opera 9.51 Build 10081 (ohne Addons) ~ 300ms Safari 3.1.2 (525.21) (ohne Addons) ~ 250ms

[Stefan Döring] Fehlerhafte WebParts in SharePoint entfernen

Stefan Döring — Wed, 13 Aug 2008 11:53:58 GMT

Gehören Sie zu jenen SharePoint-WebPart - Entwicklern, bei denen absolut jedes Projekt auf Anhieb funktioniert, der gesamte Code fehlerfrei und die web.config richtig angepasst ist? Wenn Sie diese Frage mit Ja beantworten können, sind Sie wahrscheinlich Gott und können diesen Artikel überspringen. Gehören Sie allerdings zur Gruppe der Normal - Sterblichen, so dürften Sie folgende oder eine ähnliche Seite nach dem Hinzufügen eines WebParts zu einer WebPart - Seite schon öfter gesehen haben: Natürlich können Sie nun in der web.config die CustomErrors entweder ganz oder nur lokal ausschalten und das Abrufen des Stacks erlauben, um im Browser eine aussagekräftigere Fehlermeldung anzuzeigen: und Oder Sie hängen sich einfach mit dem Visual Studio Debugger an den w3w.exe - Prozess. Meistens ist die Lösung ja auch schnell gefunden, womit das WebPart aktualisiert werden kann und die WebPart - Seite wieder läuft. Wird der Fehler jedoch nicht sofort erkannt, da er vielleicht gar nicht im WebPart selbst, sondern an einer ganz anderen Stelle (z.B. an Sicherheitseinstellungen in der web.config) liegt, so muss das fehlerhafte WebPart von der Seite entfernt werden, um diese Seite wieder lauffähig zu machen. Das Entfernen der fehlerhaften WebParts geschieht über die sog. WebPart - Wartungsseite. Diese kann z.B. folgendermaßen aufgerufen werden: Öffnen der Seitenbibliothek der Website, in welcher sich auch die fehlerhafte Seite befindet Auswahl des Menüpunktes "Eigenschaften bearbeiten" im Kontextmenüs der fehlerhaften Seite Im unteren Bereich auf "WebPartseite in Wartungsansicht öffnen" klicken Fehlerhafte WebParts markieren und auf "Löschen" klicken Wem dies zu lange dauert, der hängt einfach an die URL der fehlerhaften Seite "?Contents=1" und erreicht genauso die WebPart - Wartungsseite der Seite.

[Stefan Döring] Bilder als base64 Darstellung in Webseiten einbinden

Stefan Döring — Wed, 13 Aug 2008 09:53:20 GMT

Eine Alternative bei der Darstellung von Bildern im Web bietet sich durch die Nutzung des direkten Einbindens des Bildinhaltes im base64-Format. Der Vorteil bei diesem Vorgehen besteht darin, dass sich relativ einfach dynamische Änderungen am Bild vornehmen lassen, ohne auf eine Quelldatei angewiesen sein zu müssen. Zugegebenermaßen gibt es auch noch andere Möglichkeiten Bilder darzsutellen (Handler, Verweis auf eine .aspx-Seite, die als Response ein Bildtyp liefert, etc.), aber der Weg über die base64-Kodierung war mir bisher neu. Erzeugt wird die Ausgabe dann innerhalb des "src" Attributes des "" Elements, weshalb die Ausgabe in die Eigenschaft der "ImageUrl" geschrieben werden muss. Angemerkt sei hier aber, dass dieser Weg wohl sehr abhängig von dem verwendeten Browser ist. So funktionierte es bei meinen Versuchen nicht mit dem IE 7, wohl aber mit dem Firefox 3.01, was natürlich den Produktiveinsatz durchaus gefährdet. Schlussendlich nun der Code, um das ganze in die Realität umzusetzen: protected void Page_Load(object sender, EventArgs e) { String base64String = String.Empty; //Anfangsteil des Bilds zusammensetzen base64String = "data:image/gif;base64,"; //Dateiinhalt anfügen base64String += Convert.ToBase64String( File.ReadAllBytes(Server.MapPath("~/Bild.gif"))); //Im das "src" Tag des Bildes setzen (Asp.Net Image Steuerelement) imgBase64.ImageUrl = base64String; }

[Stefan Döring] Caching Callback in ASP.NET 2.0

Stefan Döring — Wed, 13 Aug 2008 09:41:27 GMT

Wenn Caching aus dem Code angestoßen wird, ergibt sich ein Problem, sobald man ein Callback nutzen möchte, um sich benachrichtigen zu lassen, sobald ein das Cache Item invalide wird. Da die Seite selbst die Callbackmethode aus Gründen der nur sehr kurzen Lebenszeit selbiger nicht beinhalten kann muss ein Umweg gewählt werden über eine statische Callbackmethode, welche dann genutzt werden kann. Folgender Code würde sich dann ergeben (simpler Fall für die Zwischenspeicherung eines Strings): String newContent = "Neuer Labelinhalt (zwischengespeichert)"; protected void Page_Load(object sender, EventArgs e) { if (Page.IsPostBack) { if (HelperClass.IsCacheRemoved) lblUpdate.Text = newContent; } else { Cache.Insert("Schluesselwert", "Cache Item", null, DateTime.Now.AddSeconds(1), TimeSpan.Zero, System.Web.Caching.CacheItemPriority.Default, new CacheItemRemovedCallback(HelperClass.DeleteCallback)); } } Die entsprechende Klasse enthält dann die Callback Methode, welche einen boolschen Wert setzt, der den Cache als abgelaufen kennzeichnet. Genau dieser boolsche Wert wird dann im Page_Load Ereignis der Seite abgefragt, um zu prüfen, ob eine Aktualisierung ausgeführt werden soll. An dieser Stelle wäre noch anzumerken, dass es sich sicherlich lohnen würde für die speziellen Caching Strategien beim Invalidieren des Cache-Items ein Nachladen anzustoßen, um die Daten auf Basis der Einstellungen aktuell halten zu können. Die "HelperClass" sieht dann wie folgt aus: public class HelperClass { static bool isCacheRemoved; public static bool IsCacheRemoved { get { return HelperClass.isCacheRemoved; } set { HelperClass.isCacheRemoved = value; } } public static void DeleteCallback(string key, object value, System.Web.Caching.CacheItemRemovedReason reason) { HelperClass.IsCacheRemoved = true; }

[Stefan Döring] Visual Studio 2005/2008 Profil Problem

Stefan Döring — Fri, 27 Jun 2008 12:57:54 GMT

Die letzte Zeit hat sich ein Problem ergeben, dass sich mir noch nicht in aller Ausführlichkeit erschlossen hat. Die Ausgangsituation: Es wird ein neues Projekt in VS erstellt und die entsprechenden Einstellungen für die Nutzung von Profilen vorgenommen. Nun kann aber merkwürdigerweise nicht aus den Code Behind Dateien (Default.aspx.cs) auf die Profile zugegriffen werden. Wenn man allerdings in diesem Webprojekt den Weg über Inline-Skripte geht, so kann man auf die Profilinformationen zugreifen. Da es aber meiner Meinung nach ziemlich umständlich und auch unsinnig wäre, ständig die Variablen auf andere Variablen abzubilden, sodass man von der Code Behind Datei Zugriff hat, wurde das Ganze mal kurz durchdiskutiert. Die einfachste Lösung besteht darin, beim Erstellen des Projektes eine Webanwendung zu erstellen und kein neues Projekt. Also besser: File --> New --> Web Site... als File --> New --> Project --> ASP.NET Web Application wählen und das Problem ist umgangen. Unter anderem gibt es ein Tool, dass dieses Problem als Ausgangspunkt genommen hat zu finden unter: http://code.msdn.microsoft.com/WebProfileBuilder In diesem wird auch auf den entsprechenden Blogeintrag verwiesen, der die Situation und die Features erläutert. Es umgeht das Problem, indem eine eigene Klasse erstellt wird, die dann in dem Projekt Template die fehlende Funktionalität ersetzt.

[Stefan Döring] Expression Blend 2 June Preview und Visual Studio 2008 Bug

Stefan Döring — Fri, 13 Jun 2008 12:19:58 GMT

Grad hab ich ein wenig mit Expression Blend 2 June Preview und dem Visual State Manager gearbeitet und prompt tun sich Abgründe auf: Die Zusammenarbeit von Blend und Visual Studio wird zu oft betont und nun stellte sich nach einiger Recherche heraus, dass das XAML-Tag von Visual Studio 2008 nicht erkannt wird. Das hat das Problem, dass ich mein Projekt zwar in Blend starten kann, nicht aber in Visual Studio. Fehlermeldung: The attachable property 'VisualStateGroups' was not found in type 'VisualStateManager' Die einzige Möglichkeit das ganze zu umgehen ist wohl einfach das Projekt in Blend auszuführen... Fazit: Es ist ein Bug und kein Feature!

[Stefan Döring] Silverlight 2 Beta 2

Stefan Döring — Tue, 10 Jun 2008 09:57:21 GMT

Ab der Beta 2 gibts noch eine Ergänzung der clientaccesspolicy.xml:

Den entsprechenen MSDN Link, den ich schon eine Weile gesucht hatte gibts auch noch oben drauf: http://msdn.microsoft.com/en-us/library/cc645032(VS.95).aspx

[Stefan Döring] Silverlight 2 Beta 2 TabControl

Stefan Döring — Mon, 09 Jun 2008 11:32:32 GMT

Nach der Installation aller nötigen Pakete, die für die Silverlight 2 Beta 2 Entwicklung nötig sind, sowie Expression Blend in der aktuellen Preview, wird man sich vielleicht wundern, warum das neue TabControl nicht wie gewohnt zugreifbar ist. Lösung des Problems: Referenz auf die System.Windows.Controls.Extended.dll hinzufügen (zu finden unter: "C:"Program Files"Microsoft SDKs"Silverlight"v2.0"Libraries"Client") Sodann ist noch eine kleine Kleinigkeit zu beachten, dass das neue TabControl nicht unter den Controls Tab in der Asset Library, sondern unter den Custom Controls Tab zu finden ist: So, das wars dann auch. Die "Umstände" erklären sich wahrscheinlich damit, dass die Bibliotheken umsortiert wurden, um die Downloadgrößen der XAP-Files zu reduzieren und somit die Wiederverwendung von Standardcontrols durch Auslieferung in der Silverlight 2 Beta 2 Runtime zu verbessern.

[Stefan Döring] Silverlight 2 Beta Timer Objekt

Stefan Döring — Fri, 06 Jun 2008 15:32:59 GMT

Gerade einen Eintrag gefunden, der ein interessantes und sicherlich oft benötigtes Problem darstellt. Die Sache mit der Zeit: Das Objekt der Begierde liegt in: "System.Windows.Threading" und nennt sich "DispatcherTimer". Ziemlich vertraut: die "Tick"-Methode... Quelle

[Stefan Döring] Policy Files per WCF an Silverlight senden

Stefan Döring — Fri, 06 Jun 2008 15:08:43 GMT

Bin gerade auf einen interessanten Artikel über die Auslieferung der Policy Files per WCF gestoßen: Ausschnitt: [ServiceContract] public interface ICrossDomainPolicyResponder { [OperationContract, WebGet(UriTemplate = "/clientaccesspolicy.xml")] Stream GetSilverlightPolicy(); [OperationContract, WebGet(UriTemplate = "/crossdomain.xml")] Stream GetFlashPolicy(); } Quelle: Blog by Petar Vucetin

[Stefan Döring] Silverlight 2 Beta 1 Crossdomain File

Stefan Döring — Fri, 06 Jun 2008 15:00:43 GMT

Oft gebraucht und ständig wieder gesucht die clientaccespolicy.xml:

Wobei dafür genutzt wird, die speziellen Unterpfade der Webapplikation zu separieren. Evenso kann auch das Flash-Äquivalent genutzt werden, was allerdings weniger granular genutzt werden, die crossdomain.xml: