public sealed class Kobold {
    [...]
}

Aber was, wenn der Entwickler das weitere Überschreiben einer virtuellen Methode in einer abgeleiteten Klasse verhindern möchte? Auch hier hilft das sealed-Schlüsselwort: Diesmal allerdings nicht auf Klassenebene, sondern bei der zu schützenden Methode.

public sealed override void SagHallo() {
    [...]
}

Das erneute Überschreiben dieser Methode in einer abgeleiteten Klasse wird jetzt zu einem Compilerfehler führen.

Der Schwerpunkt dieses Blogs liegt nach wie vor auf Microsoft-Technologien, allerdings diesmal deutlich breiter gefächert und nicht auf den Themenkomplex SharePoint beschränkt. So wird es hier eine Sammlung von Tipps und Tricks, kleinen und großen Snippets und Tutorials und Artikeln über den Microsoft Technologie-Stack und Software-Entwicklung im Allgemeinen geben.

Ich freue mich auf viele Kommentare, Anregungen und Diskussionen - Informationen über neue Artikel gibt's im RSS-Feed oder bei Twitter: @Spontifixus!

Was muss man also tun, um eine HyperV-Maschine in eine solche zu konvertieren, die sich im VMWare-Player abspielen lässt? Dazu braucht es einige Schritte, einige Software und einige Geduld. Vorraus-setzung für die Umwandlung der Maschine sind folgende Tools:

• Der vConverter SC - 4.2 der kostenlos von verizoncore zur Verfügung gestellt wird und
• eine Windows 7 Recovery Disk, die z.B. von Neosmart zum Download angeboten wird.

Schritt 1: Vorbereiten der Information Worker VM

Der erste Schritt auf dem Weg zu einer VMWare-fähigen Information Worker VM ist eine in einer HyperV-Umgebung aufgesetzte Information Worker VM. Die Lizenz der von Microsoft zur Verfügung gestellten VM ist leider fürs erste abgelaufen, es empfiehlt sich daher, die 10 tägige "Gnadenfrist" zur Verwendung der Maschine noch einmal zurückzusetzen bevor mit der Konvertierung begonnen wird (Start -> All Programs -> rearm -> Rearm Windows), da sonst die VM nach zwei Stunden automatisch herunterfährt.

Damit der vConverter die Konvertierung durchführen kann muss die HyperV-VM vom Hostsystem erreichbar sein. Zusätzlich muss jedes Laufwerk das konvertiert werden soll über eine Dateifreigabe verfügen, da sonst der vConverter nicht auf die Daten zugreifen kann. Stellen Sie darüber hinaus sicher, dass die Firewall des Gastsystems abgeschaltet ist (Start -> Run -> "firewall.cpl"). Sind die hier genannten Vorraussetzungen erfüllt ist die HyperV-VM erfolgreich auf die Migration vorbereitet worden.

Schritt 2: Migration der HyperV VM

Starten Sie zunächst den vConverter. Anschließend rufen Sie den Assistenten zur Erstellung einer neuen Konvertierungsaufgabe über die Symbolleiste auf.

Abb. 12: Neue Konvertierungsaufgabe starten

Im ersten Schritt des Assistenten werden sie aufgefordert den Namen des Quellsystems und die entsprechenden Zugangsdaten einzutragen. Tragen Sie hier den Namen "demo2010a" sowie den Benutzernamen "CONTOSO\Administrator" mit dazugehörigem Passwort ein.

Abb. 13: Daten des Quellsystems eintragen

Im zweiten Schritt werden Optionen der neu zu erstellenden VM abgefragt. Wählen Sie für die Art der zu erstellenden VM "VMWare®" aus. Als Ziel wählen Sie "Freigegebener Netzwerkordner" aus, und bei Ziel tragen Sie den Ordner ein, wo die migrierte VM später landen soll. Sollte der Ordner nicht auf der aktuellen Maschine liegen können Sie über die Schaltfläche "Anmeldenamen festlegen" die Zugangsdaten für den Zugriff auf den weiter oben festgelegten Ordner eintragen. Zusätzlich geben Sie den Namen der neuen VM an, z.B. "DEMO2010A".

Abb. 14: Ausgabedatei festlegen

Im nächsten Schritt wählen Sie die zu konvertierenden Datenträger aus.

Abb. 15: Zu konvertierende Datenträger auswählen

Im vierten Schritt werden die Angaben zur Hardware der zu erstellenden VM abgefragt. Hier sind ein paar mehr Einstellungen nötig. Setzen Sie in diesem Dialog den Adaptertyp auf LSI und öffnen Sie anschließend die erweiterten Einstellungen durch Klick auf die Schaltfläche "Virtual Machine konfigurieren". Im sich dann öffnenden Dialog setzen Sie den Wert für den Arbeitsspeicher auf einen Wert deutlich größer als 5000 MB, z.B. auf 7168 MB. Microsoft empfiehlt für diese VM einen Arbeitsspeicher von 8 GB.

Abb. 16: Hardware der zu erstellenden VM

Schließen Sie nun im fünften Schritt den Assistenten ab und starten Sie die Konvertierung mit einem Klick auf "Alle Aufgaben Starten" auf dem Tab "Conversion Tasks".

Abb. 17: Konvertierung starten

Die Konvertierung kann je nach verwendetem System deutlich mehr als eine Stunde Zeit benötigen. Währen die Konvertierung läuft können Sie sich über einen Klick auf das Lupensymbol des Auftrags den Fortschritt der Konvertierung anzeigen lassen.

Schritt 3: Erstellen einer startbaren VM

In den ersten beiden Schritten haben Sie eine VDMK-Datei erstellt, die die Information Worker VM enthält. Im dritten Schritt wird dieses System nun so aufbereitet, dass es vom aktuellsten VMWare Player (Version 3.1.0) abgespielt werden kann.

Der schnellste Weg zu einer lauffähigen VMX-Datei ist es, im VMWare-Player durch Klick auf die Schaltfläche "Create a New Virtual Machine" eine neue Virtual Machine anzulegen. Der sich daraufhin öffnende Assistent führt Sie in wenigen Schritten zu einer neuen nackten VM ohne Betriebssystem. Beim Erstellen der VM gehen Sie wie folgt vor: Wählen Sie im ersten Schritt die Option, das Betriebssystem später von Hand zu installieren. Im nächsten Schritt wählen Sie das Betriebssystem "Windows Server 1008 R2 x64". Im dritten Schritt geben Sie der Maschine einen Namen und einen Speicherort Ihrer Wahl. Anschließend stellen Sie eine Festplattengröße von 127 GB ein und wählen die Option die Festplatte in einer einzelnen Datei abzulegen. Klicken Sie im nächsten Schritt sie "Customize Hardware" und stellen Sie eine Arbeitsspeichergröße von 7168 MB ein. Mit einem Klick auf "Finish" beenden Sie den Assistenten.
Öffnen Sie jetzt die neuerstellte VMX-Datei mit einem Texteditor und tragen Sie in der Zeile "scsi0:0.fileName" den Pfad der in den vorherigen Schritten erzeugten VDMK-Datei der Information-Worker VM ein.

Schritt 4: Patchen des Systems

Trotz den in Schritt 3 durchgeführten Maßnahmen ist das System noch nicht lauffähig. Windows wird beim Hochfahren der VM hängenbleiben oder sich mit einem Bluescreen verabschieden. Um das zu verhindern sind einige weitere Schritte nötig. Zum Patchen des erzeugten Systems in diesem Schritt wird die Windows 7 Recovery Disk benötigt. Laden Sie dazu vor dem Starten der VM die entsprechende ISO-Datei in das DVD-Laufwerk der VM.

Starten sie die VM von der Recovery-Disk. Dazu kann es sein, dass sie während dem starten der VM sehr schnell auf "F2" drücken müssen um in die BIOS-Einstellungen der VM zu kommen. Hier wählen Sie den Reiter "Boot" und setzen dort das CD-Laufwerk an die erste Stelle der Bootreihenfolge.

Abb. 18: BIOS-Einstellungen der VM

Beim Starten von der Recovery-Disk wird Windows Fehler im Bootsektor der Festplatte finden und beheben. Starten Sie die VM danach erneut von der CD. Die Recovery-Disk fährt danach hoch und bietet dann einige Optionen. Starten Sie die Kommandozeile durch Klick auf den Button "Command Prompt", und öffnen Sie dann über das Kommando "regedit" den Windows-Registrierungseditor.

Abb. 19: Kommandozeile öffnen

Im Registrierungs-Editor selektieren Sie den Ordner "HKEY_LOCAL_MACHINE". Im Menü "File" wählen Sie anschließend "Load Hive...". Dort navigieren Sie zum Ordner "C:\Windows\System32\config" und öffnen von dort die Datei "SYSTEM". Beim Öffnen fragt der Registrierungs-Editor einen Namen ab, hier "p2v" eingeben.

Abb. 20: Load Hive...

Abb. 21: Datei "SYSTEM" öffnen

Nachdem Sie den Hive geladen haben navigieren Sie zum Eintrag "HKEY_LOCAL_MACHINE\p2v\ControlSet001\Services\LIS_SAS" und ändern dort den REG_DWORD-Wert von "Start" von 3 auf 0. Anschließend selektieren Sie den Ordner "p2v" und klicken Sie im Menü "File" den Eintrag "Unload Hive...".

Abb. 22: REG_DWORD-Wert "Start" auf 0 ändern

Zum Abschluss starten Sie die VM neu. Um die Arbeit mit der VM zu vereinfachen, empfiehlt es sich, im Anschluss an den Neustart die VMWare-Tools zu installieren. Der VMWare-Player blendet in der Regel einen entsprechenden Hinweis ein. Damit die VM nicht bei jedem weiteren Start von der Recovery-Disk startet, ist es sinnvoll, entweder die Recovery-Disk zu entladen oder die Bootreihenfolge im BIOS der VM wieder auf den ursprünglichen Wert zurückzustellen.

Mein Dank geht an Michael Greth von der SharePointCommunity, der mir die initialen Tipps gab, wie hier zu verfahren ist, sowie an die Daniel Oberli von der Seite scolab.ch, der mit sinem Tutorial den Grundstein für diese Anleitung gelegt hat.

Das folgende Beispiel basiert auf der Annahme, dass das ListTemplate "BaumListe" mit Elementen des neu definierten ContentTypes "Baum" mit den Spalten "Name" und "Kategorie" umgehen können soll.

Der erste Schritt zur Erzeugung eines solchen ListTemplates ist die Definition desselben innerhalb eines Features. Das kann man direkt in der <Elements>-Section der Datei feature.xml machen; der Übersichtlichkeit halber lagert man das aber idealerweise in eine eigene Datei aus und refernziert diese aus der Datei feature.xml. Nachfolgend der Code für die Datei feature.xml...

<?xml version="1.0" encoding="utf-8" ?>
<Feature ... >
    <ElementManifests>
        <ElementManifest Location="baumListeListTemplate.xml" />
    </ElementManifests>
</Feature>

...und für die Datei baumListeListTemplate.xml die das eigentliche ListTemplate definiert:

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <ListTemplate Type="10001"
                  BaseType="0"
                  Name="BaumListe"
                  DisplayName="Bäume"
                  Description="Liste um Bäume zu speichern"
                  SecurityBits="11"
                  Category="Custom Lists"
                  Sequence="100"
                  Image="/_layouts/images/itgen.gif" />
</Elements>

Diese beiden Dateien definieren die Eigenschaften des neuen ListTemplates. Um das Template selber nun mit Leben zu füllen, fehlt noch eine dritte Datei. Diese Datei ist die wichtigste und zugleich die umfangreichste bei der Definition eines ListTemplates.

Abb. 4: Ordnerstruktur des Features

Verfügbare Felder und ContentTypes und die Ansichten der Liste werden in der Schema-Definition des Listen-Templates definiert. Diese Datei muss immer den Namen schema.xml tragen und immer in einem Ordner liegen, der genau so heißt wie das Listen-Template. Die Ordnerstruktur in unserem Feature sieht dann in etwa so aus wie auf dem Bild rechts. Die Datei schema.xml selbst ist eine Datei, die den Entwickler zunächst durch ihre schiere Größe (gerne mehrere tausend Code-Zeilen) abschreckt. Eine einfache Möglichkeit diese Datei zu erstellen ist es daher, sie schlichtweg von einem bereits bestehenden ListenTemplate zu kopieren und sie anschließend anzupassen.

Eine noch einfachere Möglichkeit ist es, diese Datei von Grund auf selbst zu erstellen. Das ist nicht halb so aufwändig wie man glauben mag, wenn man SharePoint das machen lässt, was es bereits von Haus aus mitbringt. Grundsätzlich gliedert sich die Datei schema.xml in vier Bereiche, in denen die zugeordneten ContentTypes, die Listenfelder, die Views und die Formulare zum Anzeigen und Bearbeiten der Daten definiert werden:

<?xml version="1.0" encoding="utf-8"?>
<List ... >
    <MetaData>
        <ContentTypes> ... </ContentTypes>
        <Fields> ... </Fields>
        <Views> ... </Views>
        <Forms> ... </Forms>
    </MetaData>
</List>

Auch das List-Tag selber enthält bereits eine Menge Information über das Listen-Template:

<List xmlns:ows="Microsoft SharePoint"
      xmlns="http://schemas.microsoft.com/sharepoint/"
      Title="BaumListe"
      Direction="LTR"
      Url="Lists/BaumListe"
      EnableContentTypes="TRUE"
      BaseType="0">

Wichtigstes Attribut in diesem Zusammen ist EnableContentTypes, dass die Verwaltung von ContentTypes ermöglicht, damit der Benutzer später beim Erstellen von neuen Elementen den ContentType aus dem Menü auswählen kann, und wir bereits zur Entwicklungszeit bestimmte ContentTypes zuordnen, oder deren Zuordnung entfernen können.

Innerhalb der <ContentTypes>-Section können wir festlegen welche ContentTypes der Liste zugeordnet werden sollen. Da wir nur Bäume in unserer Liste erfassen wollen fügen wir auch nur diesen ContentType hinzu:

<ContentTypes>
    <ContentTypeRef ID="0x01000d00a9d2a1a34505af32f7c1e94abeac" />
</ContentTypes>

Innerhalb der <Fields>-Section müssen alle Felder die die Liste enthalten soll definiert werden. Standardmäßig sollten mindestens die ersten drei der im folgenden Code-Snippet gezeigten Felder definiert sein, denn diese stellen einige der Basisfeatures (Link zum Öffnen, Menü zum Bearbeiten und das Title-Feld) der Listenelemente zur Verfügung. Da wir im konkreten Fall aber den Namen des Baums anzeigen wollen setzen wir das DisplayName-Attribut auf den Wert "Name".

<Fields>
    <Field Name="LinkTitle"
           ID="{82642ec8-ef9b-478f-acf9-31f7d45fbc31}"
           DisplayName="Name"
           Type="Text"
           Sealed="TRUE"
           SourceID="http://schemas.microsoft.com/sharepoint/v3"
           StaticName="LinkTitle">
    </Field>
    <Field Name="LinkTitleNoMenu"
           ID="{bc91a437-52e7-49e1-8c4e-4698904b2b6d}"
           DisplayName="Name"
           Type="Text"
           Sealed="TRUE"
           SourceID="http://schemas.microsoft.com/sharepoint/v3"
           StaticName="LinkTitleNoMenu">
    </Field>
    <Field Name="Title"
           ID="{fa564e0f-0c70-4ab9-b863-0177e6ddd247}"
           DisplayName="Name"
           Sealed="TRUE"
           SourceID="http://schemas.microsoft.com/sharepoint/v3"
           Type="Text"
           StaticName="Title">
    </Field>
    <Field Name="BaumKategorie"
           ID="{ca8ef968-3308-4c2a-b08b-e17e686aacc3}"
           DisplayName="Kategorie"
           SourceID="http://schemas.microsoft.com/sharepoint/v3"
           Type="Text"
           StaticName="BaumKategorie">
    </Field>
</Fields>

Die <Views>-Section ist in der Regel bei weitem die umfangreichste Section der Datei schema.xml. Aber hier bietet SharePoint großes Vereinfachungspotential. Mit Hilfe des <ViewStyle>-Tags kann man nämlich aus einer Reihe von vorgefertigten Views auswählen, ohne diese explizit nochmals definieren zu müssen. Ein ganz einfacher View für unsere Baum-Liste könnte z.B. so aussehen:

<Views>
    <View BaseViewID="0"
          Type="HTML"
          WebPartZoneID="Main"
          DisplayName="All Items"
          DefaultView="TRUE"
          MobileView="True"
          MobileDefaultView="False"
          SetupPath="pages\viewpage.aspx"
          ImageUrl="/_layouts/images/itgen.gif"
          Url="AllItems.aspx">
        <ViewStyle ID="0"/>
        <RowLimit Paged="TRUE">100</RowLimit>
        <Toolbar Type="Standard" />
        <ViewFields>
            <FieldRef Name="LinkTitleNoMenu" />
            <FieldRef Name="BaumKategorie"/>
        </ViewFields>
        <Query>
            <OrderBy>
                <FieldRef Name="Title"/>
            </OrderBy>
        </Query>
    </View>
</Views>

Das <ViewStyle>-Tag referenziert die in der Datei VWSTYLES.XML im Ordner \TEMPLATE\GLOBAL\XML\ des 12-Hives der SharePoint-Installation definierten Views. Die in diesem Fall verwendete ID 0 referenziert die von SharePoint standardmäßig verwendete Listenansicht.

Zu guter Letzt braucht unser Listen-Template auch noch die Formulare zum Erstellen, Bearbeiten und Anzeigen der einzelen Listenelemente. Dafür können wir getrost das übernehmen, was SharePoint uns Standardmäßig zur Verfügung stellt:

<Forms>
    <Form Type="DisplayForm"
          Url="DispForm.aspx"
          SetupPath="pages\form.aspx"
          WebPartZoneID="Main" />
    <Form Type="EditForm"
          Url="EditForm.aspx"
          SetupPath="pages\form.aspx"
          WebPartZoneID="Main" />
    <Form Type="NewForm"
          Url="NewForm.aspx"
          SetupPath="pages\form.aspx"
          WebPartZoneID="Main" />
</Forms>

Haben wir all das erledigt und das Feature ordnungsgemäß veröffentlicht und aktiviert, können wir eine neue Liste auf Basis unseres soeben erstellten Listen-Templates erstellen, die dann hoffentlich so aussieht wie auf dem Bild ganz am Anfang des Beitrags.

Abb. 3: Kategorien

Abb. 4: Bäume

Das Lookup-Feld, in dem die Tanne der Kategorie Nadelbaum zugeordnet wird enthält den Wert 1:#Nadelbaum, der sich zusammensetzt aus der ID des refernzierten ListItems und dem Wert der anzuzeigenden Spalte.

Möchte man ein neues Item hinzufügen und diesem eine Kategorie zuweisen, reicht es allerdings nicht der Spalte einfach die ID vom ListItem zuzuweisen. Folgender Code wird nicht funktionieren:

SPListItem fichte = baumListe.Items.Add();
fichte["Kategorie"] = 1;

Statt dessen könnte man hingehen und den Wert von Hand zusammenbauen. Netterweise stellt einem SharePoint für diese Zwecke aber die Klasse SPFieldLookupValue zur Verfügung mit der sich das einfach erledigen lässt.

SPListItem katNadelbaum = kategorienListe.GetItemById(1);
SPListItem fichte = baumListe.Items.Add();
fichte ["Kategorie"] = new SPFieldLookupValue(katNadelbaum.ID, katNadelbaum.Title);
fichte.Update()

Die Klasse SPFieldLookupValue erspart einem also nicht das Nachschlagen der entsprechenden Werte, aber man bekommt auf diese Weise einfach eine gültige Zuweisung.

<Where>
    <Eq>
        <FieldRef Name="ContentType" />
        <Value Type="Text">Contact</Value>
    </Eq>
</Where>

Will man jedoch nicht nur nach allen ContentTypes eines bestimmten Typs, sondern auch nach den davon abgeleiteten ContentTypes suchen, stößt diese Methode schnell an ihre Grenzen.

Selbstverständlich könnte man über einen mehrfach verschachtelten <Or>-Operator nach vielen ContentTypes suchen - so richtig effektiv ist das aber nicht. Denn jedes Mal wenn ein ContentTyp dazu kommt, müsste man die Methoden anpassen die die Listen durchsuchen. Entsprechender Code könnte zum Beispiel relativ schnell so aussehen:

<Where>
    <Or>
        <Or>
            <Eq>
                <FieldRef Name="ContentType" />
                <Value Type="Text">Auto</Value>
            </Eq>
            <Eq>
                <FieldRef Name="ContentType" />
                <Value Type="Text">Rennwagen</Value>
            </Eq>
        </Or>
        <Or>
            ...
        </Or>
    </Or>
</Where>

Hilfreich für diese Aufgabenstellung ist es, sich das Schema ins Gedächtnis zu rufen, nach dem die IDs für die ContentTypes vergeben werden: An die ID des Eltern-Typs wird die des Kind-Typs angehängt. Unter Zuhilfenahme des <BeginsWith>-Operators ist es also ohne weiters möglich, nach ContentTypes zu suchen, bei denen der Anfang der ID mit der ID des gesuchten ContentTyps übereinstimmt. Angenommen der von uns definierte ContentType "Auto" hätte die ID 0x0100381a9daf8b3644b6b5d36f83b2b91f83, dann würde eine CAML-Abfrage, die nach "Auto" und allen davon abgeleiteten ContentTypes sucht, folgendermaßen aussehen:

<Where>
    <BeginsWith>
        <FieldRef Name="ContentTypeId" />
        <Value Type="Text">0x0100381a9daf8b3644b6b5d36f83b2b91f83</Value>
    </BeginsWith>
</Where>

Fazit: Möchte man nicht nach dem Namen der ContentTypes suchen, sondern nach dessen ID, empfiehlt es sich den Operator <BeginsWith> zu verwenden.

<%@ Control Language="C#" Inherits="WebApplication1.MyUserControl" %>
<style type="text/css">
p {
    color: #ff0000;
}
</style>
<asp:Label ID="MyLabel" runat="server" Text="MyLabel"/>

Der hier gezeigte Code würde beispielsweise folgende Designer-Ansicht produzieren:

Abb. 2: Leerer Designer

Die Erklärung für dieses Verhalten ist ebenso einfach wie unbefriedigend: Der Designer wurde ursprünglich dafür konstruiert vollständige HTML-Seiten anzuzeigen - Seiten also, die sowohl über einen <head>- als auch einen <body>-Tag verfügen. Beginnt nun das Markup mit einem <style>-, <link>- oder einem <meta>-Tag erstellt der Parser einen virtuellen <head>-Bereich um diese und alle folgenden Elemente, solage bis das er ein Element identifiziert das eindeutig dem Body einer Webseite zuzuordnen ist, wie z.B. ein <form>- oder ein <div>-Element.

Da eine ASCX-Datei normalerweise weder über ein <head>- noch über ein <body>-Element verfügt, verschluckt der Designer das <style>- und alle folgenden Tags weil er diese Elemente nicht eindeutig dem Body einer Webseite zuordnen kann. VisualStudio erkennt also nichts was zu rendern wäre und das Ergebnis ist ein leerer Designer.

Gott sei Dank gibt es allerdings den ein oder anderen Weg dieses Problem zu umschiffen. Eine Möglichkeit besteht darin, die <style>- oder <link>-Tags ans Ende des Dokuments zu verschieben. Das Layout des UserControls wird dadurch nicht beeinflusst. Ein weiterer Weg wäre den Inhalt des Steuerelements (abgesehen von den <style>- oder <link>-Tags) mit einem <div>- oder <span>-Element zu umgeben. Auch diese Maßnahme würde das Layout des Steuerelements nicht beeinflussen:

<%@ Control Language="C#" Inherits="WebApplication1.MyUserControl" %>
<style type="text/css">
p {
    color: #ff0000;
}
</style>
<div>
    <asp:Label ID="MyLabel" runat="server" Text="MyLabel"/>
</div>

Vielen Dank an den Visual Web Developer Team Blog der mir sowohl die Erklärung als auch die Lösung des Problems geliefert hat.

Grundsätzlich gibt es zwei Möglichkeiten Steuerelemente in WebParts oder UserControls einzubinden. Zum einen kann man das gewünschte Steuerelement im Quellcode eines WepParts oder UserControls instantiieren, zum anderen kann man es direkt im Markup eines UserControls oder einer ASPX-Seite verwenden. In diesem Artikel werde ich beide Varianten kurz vorstellen und zusätzlich auf eventuelle Hürden und Fallstricke beim Einsatz des Steuerelements hinweisen.

Abb. 2: DateTimeControl

Verwendung im Quellcode

Um dieses Steuerelement in einem WebPart zu verwenden reichen ein paar kurze Zeilen Code in der CreateChildControls-Methode des WebParts, die das Steuerelement der ControlsCollection desselben hinzufügen:

protected override void CreateChildControls() {
    base.CreateChildControls();
    ...
    birthdayDateTimeControl = new DateTimeControl();
    birthdayDateTimeControl.ID = "birthdayDateTimeControl" + UniqueID;
    this.Controls.Add(birthdayDateTimeControl);
    ...
}

Braucht man die Referenz auf das Steuerelement später noch an anderer Stelle, ist es natürlich sinnvoll sich die Referenz in einer Klassenvariable außerhalb der CreateChildControls()-Methode zu halten.

Verwendung im Markup

Eine weitere Möglichkeit dieses Steuerelement zu verwenden liegt in der direkten Integration in das Markup (den HTML-Quellcode) beispielsweise eines UserControls. Damit die von SharePoint bereitgestellten Steuerelement überhaupt verwendbar werden ist zunächst ein zusätzlicher Tag-Prefix zu registrieren. Auch hier wird die oben erwähnte Assembly referenziert:

<%@ Register TagPrefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls"
Assembly="Microsoft.SharePoint, Version=12.0.0.0,
          Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

Anschließend kann das Steuerelement einfach ins Markup des UserControls eingebunden werden. Folgend beispielhaft der Code um das Steuerelement innerhalb einer Tabelle zu verwenden:

<%@ Register TagPrefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls"
Assembly="Microsoft.SharePoint, Version=12.0.0.0,
          Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

Im Gegensatz zum oben erläuterten Einsatz des Steuerelements über den Quellcode brauchen wir hier keine Sorge zu tragen, dass die ID des Steuerelementes seitenweit eindeutig ist. Diese Aufgabe nimmt SharePoint uns dankenswerter Weise ab. Nichtsdestotrotz muss die ID des Steuerelementes innerhalb des UserControls immernoch eindeutig sein!

Netterweise stellt das DateTimeControl bereits einen RequiredFieldValidator zur Verfügung, um zu prüfen ob der Benutzer einen Wert in das Feld eingetragen hat oder nicht. Möchte man allerdings z.B. die Werte zweier DateTimeControls miteinander vergleichen muss man einen kleinen Umweg gehen. Intern werden für jedes DateTimeControl eine TextBox für das Datum und zwei DropDownBoxen für die Stunden und Minuten erzeugt. Die IDs dieser Controls entsprechen jeweils der ID des DateTimeControls mit einem Anhang. Die TextBox für das Datum hat den Anhang "Date", die DropDownBox für die Stunden den Anhang "DateHours" und die für die Minuten den Anhang "DateMinutes".

Auf diese Controls kann nun recht einfach zugegriffen werden. Da das anzusprechende Steuerelement aber ein Kindelement des DateTimeControls ist, muss dessen Index dem Validator - getrennt durch ein Dollar-Zeichen ($) ebenfalls mitgegeben werden. Für das Steuerelement "FirstControl", dessen Datumswert mit dem des Steuerelements "SecondControl" verglichen werden soll, sähe z.B. ein Validator zum Vergleichen zweier Datumswerte folgendermaßen aus:

<asp:CompareValidator
    ID="MyValidator"
    ControlToValidate="FirstControl$FirstControlDate"
    ControlToCompare="SecondControl$SecondControlDate"
    Type="Date"
    Operator="GreaterThan"
    runat="server"
    ErrorMessage="..."
</asp:CompareValidator>

Und ich will auch gar nicht lange um den heißen Brei herumreden, sondern gleich mit einem kleinen Tipp einsteigen. Definiert man in einer Feature-Definition eine eigene Liste und möchte einer dazugehörigen Spalte einen Standard-Wert verpassen hat man auf den ersten Blick eine Menge Möglichkeiten. Aber nur weil einige der XML-Tags Attribute wie DefaultValue zulassen heißt das noch nicht, dass der dann auch später von SharePoint so verstanden wird.

Die Lösung einer Spalte einen Standardwert zuzuweisen liegt in der Datei schema.xml eines Listen-Templates. um hier einer Spalte einen Default-Wert zuzuweisen reicht es innerhalb des <Field>-Tags den <Default>-Tag zu verwenden. Beispiel:

<Field ID="..." Name="..." ...>
    <Default>Mein Standardwert</Default>
</Field>