Probleme mit VerifyRenderingInServerForm

Wer in Zeiten von Web 2.0 und AJAX (andere Gründe solls natürlich auch geben ;-)) schon mal den HTML-Code eines GridViews mit der Methode RenderControl() erzeugen wollte, ist villeicht schon mal über die Fehlermeldung

Das Steuerelement  vom Typ GridView muss in einem Formulartag mit runat=server positioniert werden.

gestolpert.
Das Problem kann auf einfache Art und Weise (wenn auch unverständlich) mit dem Überschreiben der Methode VerifyRenderingInServerForm() behoben werden.
Dazu muss einfach diese Methode überschrieben werden, ohne dass sie etwas tut.

public override void VerifyRenderingInServerForm(Control control)
{
}

Siehe da, die Fehlermeldung ist weg. Wer genauer wissen möchte was die Methode normalerweise macht kann bei Microsoft nachlesen.
Für mich fällt dieses Vorgehen unter die Rubrik "Kopf schütteln, verwenden und nicht weiter damit belasten ;-)"

GridView-Spalten dynamisch anzeigen

Manchmal kommt man in die Verlegenheit, über ein GridView Spalten dynamisch anzuzeigen, z.B. wenn man mit einem GridView verschiedene Tabellen darstellen möchte; aber ohne die AutoGenerateColumns-Eigenschaft.
Das Vorgehen ist recht einfach:

BoundField dynField = new BoundField();
dynField.DataField = "SpaltenName";
dynField.HeaderText = "Überschrift im GridView";
GridviewControl.Columns.Add(dynField);

Verschiedene DLL-Versionen in einem Workflow verwenden

Die Windows Workflow Foundation hat einiges zu bieten! In vielen Fällen wird es bei der Verwendung von Workflows zu längeren "Laufzeiten" kommen. D.h. zwischen den verschiedenen Schritten kann es natürlich durchaus vorkommen, dass mal Tage Wochen oder noch mehr Zeit vergeht. Während dieser "inaktiven" Zeit wird der Workflow zwischengespeichert (z.B. auf einem SQL-Server). Damit kann auch ein Serverreboot oder Ähnliches die Wiederaufnahme des Workflows nicht verhindern.
Bei der Speicherung des Workflows wird ein komplettes Abbild des aktuellen Zustandes gespeichert. Das bedeutet, dass alle Einstellungen etc. weggespeichert werden, somit auch die Zustände eigener Klassen (z.B. der Wert einer Property o.ä).
Was ist aber wenn sich während der Zeit eines ruhenden Workflows eine neue Version der eigenen Klassen und deren DLL auf den Server gespielt wird (z.B. bei einem Workflow in einer ASP.NET-Anwendung), und diese Version neue, erforderliche Properties verwendet oder noch schlimmer - alte nicht mehr vorhanden sind? Bei Wiederaufnahme des Workflows würde eine derartige Änderung ev. in einer Exception enden und das Programm/Workflow könnte nicht zu Ende geführt werden.
Dafür gibt es eine einfache Lösung: man verwendet den GAC anstatt dem bin-Verzeichnis der Web-Anwendung, da im GAC veschiedenen Versionen einer DLL abgelegt werden können. Alte Worklfows könnten damit auf die "alte Art und Weise" beendet werden, neue könnten die neue Version verwenden.