SharePoint Workflow – DateTime und abweichende Stunden

In einem SharePoint Workflow habe ich verschiedenste Berechnung mit Daten (Datum). Sei es, dass ich zwei Daten voneinander subtrahiere um eine Zeitspanne zu erhalten oder eine definierte Zeit zu einem Datum dazu rechne um das Fälligkeitsdatum einer Aufgabe zu bestimmen.

Dabei bin ich immer wieder auf das Selbe Problem gestoßen. Der Workflow reagierte auf meine gesetzte Daten manchmal 2h später als angegeben.

Nach langer Suche stellt sich heraus, dass das Problem darin besteht wie SharePoint Daten speichert. Tatsächlich konvertiert SharePoint Daten nach UTC….! Ich habe also Berechnungen mit Daten zweier verschiedenen Zeitzonen durchgeführt, da z.B. Benutzereingaben in meiner Umgebung in der aktuellen MEZ angegeben werden. Das Ergebnis lag somit manchmal 2h in der Vergangenheit, ein anderes mal 2h in der Zukunft.

Ich habe im SharePoint-Designer in einem 2010er Workflow noch keine möglichkeit gefunden ein Datum automatisiert in die richtige Zeitzone zu konvertieren. Lediglich ein paar Drittanbieter-Actions habe ich gesehen die das scheinbar können.

Wenn du also im Code/Workflow mit Datum arbeitest, vergesse nicht, in UTC zu konvertieren bzw. sicherzustellen, dass alle Eingaben und Vergleichsdaten in UTC vorliegen.!

[c#] Objekte ohne Namensraum und Deklaration in XML serialisieren.

Heute wollte ich ein Objekt nach Plain XML ohne Namespaces und ohne XML-Deklaration serialisieren. Der XmlSerializer fügt jedoch einen Standard Namespace und die XML-Deklaration automatisch ein. Um das zu vermeiden gibt es die folgende Möglichkeit:

WinForms Cue TextBox

Eine Möglichkeit mit wenig Aufwand eine TextBox mit einem Platzhalter (Cue-Banner) zu erstellen. Erstelle hierfür eine neue Klasse in deinem Projekt und füge den unten gezeigten Code ein, dann kompilieren. Platziere nun das neue Steuerelement/Control in deiner Form und setze die Cue-Eigenschaft.

Du erhälst eine Live-Vorschau des Cue-Wertes im Designer, lokalisiert auf die Spracheigenschaft des Formulars.

 

Cache, Session, ViewState und warum überhaupt?

Bei einem meiner letzten Kundenprojekte kam kürzlich die Meldung rein, die Anwendung würde nicht mehr und/oder nur langsam reagieren. Kann nicht sein, dacht ich mir. Eine kurzer Blick in den IIS und die offenen Anfragen belehrte mich dann doch recht beeindruckend – es waren einige hunderte, gar tausende Anfragen offen. Ein paar Tests und einiges an Recherche später war der Übeltäter schnell ausgemacht. Sein Name – HttpSessionState.

Unwissenheit und Faulheit brachte mich dazu das Session-Objekt der aktuellen Sitzung als Caching-Mechanismus zu missbrauchen. Der Plan: Das Ergebnis sich oft wiederholender und statischer Datenbankabfragen zwischen zu speichern um dadurch die Anzahl der Zugriffe zu minimieren und die schlussendlich die Performance zu verbessern. Das Problem: Eine Anfrage an eine .NET-Webanwendung führt zu einem Session-Lock der erst nach Auslieferung der Antwort wieder gelöst wird. IIS arbeitet Anfragen die das Session-Objekt nutzen also nicht parallel sondern nacheinander ab.

Um zu dieser Erkenntnis zu kommen musste ich das Thema Caching jedoch erst einmal verstehen.

„Cache, Session, ViewState und warum überhaupt?“ weiterlesen