manik.net

Ganz kurz: WebClient mit eigenem Verbindungs Timeout (WebClient with a custom connection timeout)

2008-06-16T12:28:18Z

English: As I'm having a few english readers I'm going to add english post subjects whenever I'm posting interesting and helpful code-snippets :) The topic says it all, it shows you how to add a timeout to the WebClient class.

...und jetzt wieder auf Deutsch :-) Vorher hat mich die Frage erreicht wie man denn den WebClient mit einem Timeout versehen kann, da es ja für gewöhnlich heisst, man müsse in solchen Fällen auf die HttpWebRequest-Klasse zurückgreifen. Das stimmt jedenfalls nicht, denn man kann eine Klasse von der Klasse WebClient ableiten und dann die Methode GetWebRequest überschreiben und das WebRequest objekt, welches vom WebClient verwendet wird, nach belieben modifizieren.

Im folgenden Code sieht man wie simpel und genial so etwas in C#/.NET aussehen kann:

public class TimeoutWebClient : WebClient
    {
        private int _timeOut = 10000;
        public int TimeOut
        {
            get
            {
                return _timeOut;
            }
            set
            {
                _timeOut = value;
            }
        }

        protected override WebRequest GetWebRequest(Uri address)
        {
            WebRequest webRequest = base.GetWebRequest(address);
            webRequest.Timeout = _timeOut;
            return webRequest;
        }
    }

Okay, das war's auch schon für Heute :) Viel Spaß mit dem angepassten WebClient!

Linq: DataContext in einer Web-Anwendung? Statisch? Bei jedem Aufruf? Wie denn bitte?!

2008-06-10T01:24:44Z

Diese Frage stellt sich wohl jeder wenn man Linq-to-SQL in einer Web-Anwendung verwenden möchte. Microsoft sagt dazu folgendes: "A DataContext shoud be use per unit of work". Das heißt soviel wie, man sollte einen DataContext instanzieren für jede Arbeitseinheit die Anfällt, ich denke mal damit ist jeder INSERT/UPDATE/SELECT Befehl gemeint. Ist allerdings meiner Meinung nach etwas viel da so ein Datacontext einiges an Overhead mit sich bringt.

Also? Was machen wir dann? Lösen wir das Problem in dem wir unseren DataContext in unserer Webanwedung einfach statisch deklarieren? Nein. Das würde einiges an Problemen mit sich bringen, zum Beispiel wenn Objekte "InsertOnSubmit" markiert werden während ein "SubmitChanges" Aufruf ausgeführt wird. Aber das ist auch nur eines der *vielen* Probleme.
Die Lösung ist Simpel, wir verwenden einen DataContext für jeden Request der beim Server ankommt. Mit dieser Methode hatte ich bisher noch keine Probleme und die Last auf dem Server ist auch nicht so gigantisch, da wir den DataContext auch nur instanzieren sollten wenn er gebraucht wird. Zusammen mit der .net 3.x Spracherweiterung mit der wir Instanz-Methoden in vorhanden Klassen "injizieren" können. Die Idee ist, dass wir unseren "Per-Request-DataContext" dann über das "Request"-Objekt aufrufen können. Den passenden Codeschnipsel gibt's natürlich auch:

public static class HttpContextExtension
{
   private static object _key = new object();

   // extend HttpContext class
   public static DataContext GetDataContext(this HttpContext httpContext)
   {
      if (httpContext.Items[_key] == null)
          httpContext.Items[_key] = new DataContext();
      
      return httpContext.Items[_key] as DataContext;
   }
}

Die HttpContextExtension-Klasse sollte dann in einen Namespace der überall dort eingebunden ist, wo man auf die Context.GetDataAcessObject() Methode zugreifen möchte.
Übrigens, das "this" Schlüssel wort am ersten Parameter markiert diese statische Methode als Methode die in die klasse HttpContext injiziert wird.

.csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; }

70-528? Bestanden!

2008-06-10T01:01:36Z

So, letzten Mittwoch habe ich dann endlich auch die 70-528 Prüfung bestanden und bin jetzt offiziell "Microsoft Certified Technology Specialist" :)

Microsoft Exam: 70-536 - bestanden!

2008-05-27T10:38:51Z

Ich hatte heute Morgen mein erstes Microsoft Examen, das "Microsoft .NET Framework - Application Development Foundation" und habe das natürlich bestanden ;).

Vorbereitet habe ich mich mit der üblichen, von Microsoft vorgeschlagenen, Lektüre. Als nächstes steht das 70-526 an, welches ich im Laufe der nächsten Wochen absolvieren möchte.

In der nächsten Zeit werde ich außerdem etwas, naja eher viel, über Linq-to-SQL schreiben.
Wieso? Weil ich Linq zum ersten mal in einer echten n-Tier Webapplikation mit kompletten "Business Object Layer" eingesetzt habe. Alles in allem muss ich sagen Linq ist "heiss". Zusammen mit dem .NET Framework 3.5 habe ich da ein paar echt nützliche Techniken entwickelt, für jeden den das Thema Linq in Kombination mit ASP.net interessiert sollte das ein "must-read" werden.
Für diejenigen die es interessiert: das Projekt ist eine Musik-Suchmaschine a la google, momentan noch nicht ganz fertig - wird aber bald live geschaltet.

C# und ASP.Net Performance Optimierungen

2008-04-18T13:30:00Z

Hier mal in Stichworten ein paar Grundsätze die man beim Entwicklen beachten sollte, wenn Laufzeit-Performance eine Rolle spielt:

C# Performance Optimierungen:

Lieber wenig große wie viel kleine Assemblys
„sealed“-Klassen wann immer möglich bei geerbten Typen mit vielen virtuellen Funktionen. Die virtuellen aufrufe werden dann „inline“ teil der Klasse.
„Equals“ überschreiben bei Value-Types ( struct valuetype ) , vermeidet Reflektionskosten
Propertys sind teurer wie öffentliche Attribute. Bei einfach switches eher öffentliche Attribute verwenden (z.B: public bool Debug).
Boxing vermeiden! Fixe Typen wann es geht.
for anstatt foreach
so wenig funktionsaufruf in einem loop wie möglich, d.h. auch rekursive Aufrufe vermeiden - auch Property zugriffe sollte so gut wie möglich vermieden werden
„jagged arrays“ anstelle von multidimensionalen arrays.
string[][] jaggedArray = new string[2][];
jaggedArray[0] = new string[4];
jaggedArray[1] = new string[1];
jaggedArray[0][1] = “performance!”;

MSIL kann eindimensionale Arrays besser optimieren wie mehrdimensionale.
Auf MSIL ebene sieht man den unterschied:

int [,] secondarr = new int[1, 2];
secondarr[0, 0] = 40;

MSIL:

IL_0029: ldc.i4.s 40
IL_002b: call instance void int32[0...,0...]::Set(int32, int32,in32)

Mit einem Jaggedarray sieht das ganze dann auf MSIL so aus:

IL_001c: ldc.i4.s 40
IL_001e: stelem.i4

stelem = „store an element“

Bei mehrdimensionalen Arrays wird der ganze „Generic Type“-Kram also betrieben was einiges an Overhead erzeugt.
Bei string vergleichen wo Groß-/Kleinschreibung ignoriert werden soll CompareTo anstatt a.ToLower()==b.ToLower() da die ToLower operation zusätzliche strings erzeugt
(try/catch)-blöcke vermeiden, lieber den Code sicher schreiben (null checks etc.) und gut prüfen

ASP .Net Optimierungen:

Roundtrips vermeiden: Server.Transfer anstelle von Response.Redirect (es wird kein Responseheader zurück geschickt der einen Redirect auf dem Clienten verursacht, d.h. die Url im Browser ändert sich auch nicht, allerdings spart man dadurch einen Roundtrip)
Lange Control.ID zuweisungen vermeiden
Tiefe Control Schachtelungen vermeiden
Viewstate ausschalten wenn nicht benötigt, am besten nicht per Control sondern per page
wann?
-> die seite macht kein postback mit informationen verschiedener controls (5 textboxen auf einer seite)
-> controls haben keinen dynamischen inhalt oder werden mit jedem postback neu befüllt
Page.IsPostBack property verwenden um eine mehrfach initialisierung zu vermeiden
Page.DataBind() vermeiden -> jedes control das DataBinding unterstützt wird dann gebundend. -> notwendige controls einzeln binden
Eval(##) vermeiden lieber explizit Casten und Daten von hand auswerten, spart Reflektionskosten

(Child) Controls finden auf der gesamten Page

2008-01-17T12:06:12Z

Leider bietet ja FindControl nur die möglichkeit das/die aktuelle Control/Page zu durchsuchen. Was ist aber wenn man ein Childcontrol eines nachbar Controls sucht auf das die aktuelle Page/Control kein Zugriff hat? Man braucht eine Funktion mit der man rekursiv nach einer Control.ID suchen kann. Diese Funktion gibts nicht direkt im .net Framework aber auf meinem Blg und zwar hier:

          1: T FindControl<T>(string id, Control root) where T : class

         2: {

         3:  

         4:     if (root == null)

         5:         return null; 

         6:  

         7:     Control control = root.FindControl(id); 

         8:  

         9:     if (control != null)

        10:         return control as T; 

        11:  

        12:     foreach (Control childControl in root.Controls)

        13:     {    

        14:         if (childControl == null)

        15:             continue; 

        16:  

        17:         if (childControl.Controls.Count <= 0)

        18:             continue; 

        19:  

        20:         T match = FindControl<T>(id, childControl); 

        21:  

        22:         if (match != null)

        23:             return match;

        24:     }

        25:     return null;

        26: }

        27:

Wenn wir ein Updatepanel von einem Customcontrol aus auf der gesamten Page suchen mit dem namen "MyAjaxPanel" dann würde die Funktion wie folgt gerufen:

UpdatePanel updatePanel = FindControl<UpdatePanel>("WatchlistAjaxPanel", this.Page)

Man übergibt also den Typen des Controls das man sucht, das erspart uns überflüssiges type-casting. Falls der Typ unbekannt ist kann man aber auch ganz einfach nach dem "Control" Typen suchen, also:

FindControl<Control>("WatchlistAjaxPanel", this.Page)

Ajax UpdatePanel.Refresh() auslösen per Javascript

2008-01-06T12:27:00Z

Vor ein paar Tagen musste ich ein Ajax UpdatePanel.Refresh() per JavaScript auslösen, der Haken daran war es mussten auch noch Zusatzinformationen an den Server übertragen werden.
Die Lösung ist man ruft die JavaScript Funktion "__doPostBack" aus und übergibt als EventTarget die ClientID des UpdatePanel das zu refreshen gilt. Die Zusatzinformationen werden dem EventArgument Parameter der "__doPostBack" Funktion übergeben.
Wenn man keine Parameter bzw. Zusatzinfos an den Server übertragen möchte - also nur das Updatepanel refreshen ist das ganze ziemlich einfach.

Javascript Code:

function refreshUpdatePanel( updatePanelClientID ){     __doPostBack( updatePanelClientID, '' );}

Dazu der passende C# Code:

button.OnClientClick =     "BLOCKED SCRIPTrefreshUpdatePanel( '" + updatePanel.ClientID + "' );"+    "return false;";

Zu beachten ist hier lediglich das "return false" am ende des OnClientClick JavaScripts.
Dieses verhindert einen asp.net postback zurück an den server.

Wenn man Parameter/Zusatzinformationen an den Server zurück schicken möchte wird das ganze allerdings etwas komplizierter.

Javascript Code:

function refreshUpdatePanelParameterized( updatePanelClientID, eventArgumentName ){    // do javascript stuff to populate event arguments here, like get all checked checkboxes    // or other clientside control content and send it back to the server    // i'll use "nothing" as argument placeholder here    var eventArguments = 'nothing';        __doPostBack( updatePanelClientID, eventArgumentName + '_#_' + eventArguments);}

C# Code:

protected void Page_Init(object sender, EventArgs e){    if ( Request.Params["__EVENTTARGET"] == updatePanel.ClientID )    {        string[] eventsArgs = Request.Params["__EVENTARGUMENT"].Split( new string[]{"_#_"}, StringSplitOptions.RemoveEmptyEntries );        string argumentName = eventsArgs[0];        string argumentValue = eventsArgs[1];         System.Diagnostics.Debug.WriteLine(string.Format("Recieved command {0} with values {1}.", argumentName, argumentValue ) );    }             } protected void Page_Load(object sender, EventArgs e){    button.OnClientClick = "BLOCKED SCRIPTrefreshUpdatePanelParameterized( '" + updatePanel.ClientID + "', 'arg1' ); return false;";}

Wie das geschulte Auge erkennt werden hier zwei Parameter übertragen, ArgumentName und ArgumentValue. Der "refreshUpdatePanelParameterized" wird der ArgumentName (hier: "arg1") übergeben und die Funktion selbst ermittelt dann noch im JavaScript die ArgumentValue (hier: "nothing" ) und schickt die Informationen als Postback an den Server.
Der Serverseitige C# code "entschlüsselt" diese Informationen wieder in argumentName und argumentValue und verwertet diese anschließend.

Performance Timing mit ‚using’ und delegates mit „Conditional“ Methoden

2007-12-21T12:18:00Z

Letztens musste ich die (zeitliche) Performance einer sehr CPU/IO lästigen Operation verbessern.
Da die Operation in diverse kleinere Vorgänge unterteilt war musste ich die Vorgänge ermitteln, welche am meisten Zeit in Anspruch nahmen und das meiste Optimierungspotential hatten. Dafür hab ich eine Klasse entworfen die mit dem „using“-Mechanismus die Dauer einer Operation ermittelt. Dabei bin ich auch darauf gestoßen, dass der C# Compiler Methoden die das „Conditional“ Attribut haben nicht delegates zuweisen kann.

Also, nun zu der Klasse:

     public class PerformanceTiming : IDisposable

    {

     public delegate void LogPerformance(string value);

     private DateTime _startTime;

     private string _name;

     private LogPerformance _logPerformanceMethod;

     private const string _startMessage = "PerformanceTiming={0}: Start={1}";

     private const string _endMessage = "PerformanceTiming={0}: End={1} Duration={2}msec";

     public PerformanceTiming(string name)

     {

      // cannot directly use Debug.WriteLine(string) as it has the "Conditional" attribute.

      //  _logPerformanceMethod = System.Diagnostics.Debug.WriteLine(value);

      // have to use wrapper function

      _logPerformanceMethod = DebugWriteLineWrapper;

      _name = name;

      _startTime = DateTime.Now;

      _logPerformanceMethod(string.Format(_startMessage, _name, _startTime.ToLongTimeString()));

     }

     public PerformanceTiming(string name, LogPerformance logPerformanceMethod)

     {

      _logPerformanceMethod = logPerformanceMethod;

      _name = name;

      _startTime = DateTime.Now;

      _logPerformanceMethod(string.Format(_startMessage, _name, _startTime.ToLongTimeString()));

     }

     public void DebugWriteLineWrapper(string value)

     {

      System.Diagnostics.Debug.WriteLine(value);

     }

     #region IDisposable Members

     public void Dispose()

     {

      _logPerformanceMethod(string.Format(_endMessage, _name, DateTime.Now.ToLongTimeString(), (DateTime.Now - _startTime).TotalMilliseconds));

     }

    #endregion

    }

Mehr oder weniger simple, ja, aber es ist eigentlich auch die Idee bzw. die Anwendung der Klasse was die Sache so sinnvoll macht.

using (PerformanceTiming performanceTiming = new PerformanceTiming("HeavyWork"))
{
System.Threading.Thread.Sleep(2000);
}

Damit wird der folgende Output in den Debugoutput stream geschrieben:

PerformanceTiming=HeavyWork: Start=13:12:16
PerformanceTiming=HeavyWork: End=13:12:18 Duration=1999,6672msec

Es wird also die Start-/Endzeit der Operation ausgegeben, plus die Dauer in Millisekunden.
Die Ausgabe kann natürlich ohne Probleme angepasst werden.
Man kann auch eine Methode an das PerformanceTiming Objekt übergeben, welcher dann die Ausgabestrings übergeben werden, so z.B. Console.Writeline.

using (PerformanceTiming performanceTiming = new PerformanceTiming("HeavyWork", Console.WriteLine))
{
System.Threading.Thread.Sleep(2000);
}

Man könnte natürlich auch jede andere Funktion die nur einen (string) Parameter hat übergeben, z.B. StreamWriter.WriteLine um Direkt in eine Datei zu loggen.

Conditional Methoden und delegates, wie macht man das? Man schreibt einfach eine Wrapper funktion die nicht das [Conditional("DEBUG")] Attribut besitzt.

So wird aus:

_logPerformanceMethod = System.Diagnostics.Debug.WriteLine;

Das:

_logPerformanceMethod = DebugWriteLineWrapper;
public void DebugWriteLineWrapper(string value)
{
System.Diagnostics.Debug.WriteLine(value);
}

So, das war nun mein erster mehr oder weniger Sinnvoller Blogeintrag :-)

EDIT: Wie postet man eigentlich code-snippets hier?

EDIT2: I now know the answer thanks to my friend Brendan from Orcs, Goblins and .NET, I will blog about it in a few days.

Hi

2007-12-21T11:52:00Z

Es heisst der erste Blogpost ist der schwerste. So ist es auch tatsächlich, aus diesem Grund werde ich den Blogeintrag an dieser Stelle abbrechen.

Der beleuchtete Neon-Platin Gullideckel