19.07.2012
17:03

Sharepoint - Verwaiste SiteCollection finden und aufräumen

Sharepoint, die einen lieben, die anderen hassen es und ich weiss immer noch nicht so recht was ich davon halten soll.

Mein bis jetzt gröbstes Projekt in Sharepoint ist die Aufbereitung und Transformation von Daten aus 3 alten Sharepoint-Lösungen (SP 2007), damit diese in eine neue Lösung importiert werden können. Der Metadaten-Ansatz hat sich dabei als sehr hilfreich heraus gestellt. Diese Metadatenschicht besteht aus knapp. 4 GB an Daten, was ca. 0.2% des Gesamtdatenvolumen der Migration entspricht.

In der Zukunft und Big Data wird das für Entwickler mit der Einstellung: "Die Datenhaltung ist mir scheiss egal" noch eine echte Knacknuss werden. Denn solche Datenmengen bestrafen diese Einstellung, ganz gleich ob SQL oder NoSQL.

Ein Problem in Sharepoint sind unter anderem verwaiste SiteCollections, die zudem doppelt vorhanden sein können. Solch eine Konstellation kann die Sharepoint Deployment Content API aus dem Tritt bringen und die Datenaufbereitung erschweren.

Mittlerweile habe ich gelernt, dass der Lösungsweg für dieses Problem eine Datenbank-Reparatur ist.

Der Befehl dafür lautet:

 


stsadm -o databaserepair -databasename <<Datenbank>> -url http://Site

bzw. ab SP 2010 mit Powershell (Merci an Thorsten Hans für den Tipp):


Add-PSSnapIn Microsoft.SharePoint.PowerShell 
$db = Get-SPDatabase "<<Datenbank>>"; 
$db.Repair($false); 
$db.Update();

In der Metadatenebene haben gerade die doppelten SiteCollections, von der jeweils eine verwaist war, den Logmechanismus aktiviert. :) Einfach ausgedrückt, diese haben es nicht aus der Staging-Area heraus geschafft, so dass die Integrität der Metadaten jederzeit gewährleistet ist. Im Log ist dann ersichtlich welche der vielen Datenbanken eine Datenbankreparatur erfordern, damit die Sharepoint Content Deployment API wieder fehlerfrei bei diesen SiteCollections arbeiten kann.

Weitere Informationen zum Thema:

17.07.2012
23:04

T4 TemplateFileManager als NuGet Package

Aktuell beschäftige ich mich ein wenig intensiver mit NuGet. Nachdem ich einen eigenen NuGet-Server in wenigen Schritten erstellen konnte, um firmeninterne Optimierungen testen zu können, interessiert mich nun verstärkt die Bereitstellung von Content-Packages. Gerade für die kommende App-Entwicklung mit Schwerpunkt Javascript, HTML und REST kann T4 seine stärken gegenüber CodeDOM viel besser ausspielen.

Als erstes habe ich dies mit dem TemplateFileManager ausprobiert. Das erste Resultat ist hier verfügbar und kann mit folgenden Befehl installiert werden:

PM> Install-Package T4.TemplateFileManager

Im Paket ist auch ein Beispiel zur Verwendung enthalten. In einer weiteren Phase werde ich dieses wieder entfernen und ein NuGet-Package bereitstellen, welches nur aus Beispielen bestehen wird.

Aktuell steht nach der Installation eine SimpleSample.tt - Vorlage zur Verfügung, die den Einsatzzweck veranschaulichen soll. Dazu wird auch ein ParameterTemplate verwendet, um die Ausgabelogik von der Verarbeitungslogik zu trennen. Für mich hat sich diese Vorgehensweise als sehr praktisch herausgestellt, da so bspw. bei der Generierung von Schnittstellen für einen WCF-Service auch die Konfigurationseinstellungen erstellt, aber auch einfacher ersetzt werden können.

Nach der erfolgreichen Installation hat das Projekt folgende Elemente:

Abbildung 1 Sichtbare Elemente SimpleSample.tt, SimpleParameterTemplate.tt und TestFolder in dem die Ausgabe von SimpleSample.tt erzeugt wird
Abbildung 1
05.06.2012
13:16

Neue Möglichkeiten mit dem T4-Editor von Tangible

Der T4-Editor von Tangible hat ein paar neue Funktionen verpasst bekommen. Was mir am besten gefällt, ist die bessere Integration in Visual Studio. Microsoft selbst schaffte es nicht, obwohl ankündigt, die Intellisense in VS 2012 für T4 zu ermöglichen.

In dieser Hinsicht gibt nachfolgendes Video einen kurzen und informativen Überblick über die wichtigsten Neuerungen.

Entity Framework 4.3 - Building Blocks oder wie steuer ich die Datenbankversion

Gelegentlich kommt es vor, dass die Datenbankversionen pro Umgebung unterschiedlich sein können. Bei meinen ersten versuchen ist mir das mit den SQL-Server Versionen 2005 und 2008 so ergangen.

Sofort ersichtlich wurde das, wenn die folgende Fehlermeldung im Log zu sehen war:

System.ArgumentException: The version of SQL Server in use does not support datatype 'datetime2'

Um dies in den Griff zu bekommen gibt es das Attribut "ProviderManifestToken" in der EDMX-Datei. Mit dem ERM-Ansatz lassen sich, neben unterschiedlen Datenbanken, auch unterschiedliche Versionen einer Datenbank verwalten und mappen. Ein sehr interessanter Ansatz bei der Realisierung von Standardsoftware.

Nun stellt sich die Frage, wie mache ich das in Code First mit Schema Migrations?

Der Schlüssel liegt dabei in der Klasse DbModelBuilder. Beim erstellen kann damit die Datenbankversion definiert werden.


// default
var model = builder.Build(connection);

// with version
var model = builder.Build(new DbProviderInfo("System.Data.SqlClient", "2005"));

Gerade mit der nächsten Version von SQL Server 2012 wird es sicherlich ähnliche Probleme geben können, wenn die Systemumgebungen trotz ITIL nicht ganz so synchron sind. Bei der erstmaligen Erstellung des Models wird das sicherlich nicht von Bedeutung sein, wohl aber bei Schema Migrations.

Im Blogbeitrag von Arthur Vickers finden sich noch andere interessante Punkte die interessant sind, so auch die Aussage das Pluggable Conventions für den Durchschnittsentwickler frühstens mit EF6 nutzbar werden, wenn überhaupt.

Weitere Informationen zum Thema:

Entity Framework 4.3 Mapping Szenarien

Vor ein paar Wochen wurde über Twitter gefachsimpelt, welche Vererbungsstrategie Standard bei Code First ist. Es kam sehr schnell die Antwort TPT. Da ich diesen Bereich mit der Version 4.1 durchgetestet habe und eigentlich TPH der Standard ist, wollte ich nun überprüfen, ob sich etwas zur Version 4.3 geändert hat.

Mit Partick Weibel hatte ich vor 2 Jahren im Bereich der Mapping Strategien eine Präsentation zum Thema "Übersicht zwischen NHibernate und dem Entity Framework" bei der .NET User Group Bern gehalten. Der Schwerpunkt lag dabei auf Business Value, weniger auf Religion.

Diese Beispiele habe ich auch für den Code First Ansatz mit dem Entity Framework nachgeführt, um die Unterschiede zwischen den Vorgehensweisen Bottom Up (DB First), Middle Out (Model First) und Top Down (Code First) zu visualisieren. Herausgekommen ist dabei folgende Übersicht:

Abbildung 1 Mapping Szenarioen (mb = Fluent API)
Abbildung 1

Diese Beispiele habe ich nun auf die Version 4.3-1 aktualisiert und die Standardvererbung überprüft. Es ist immer noch die Strategie TPH. Meine Übersicht ist auch mit der Version 4.3 noch aktuell. ;-)

Im Bereich der Vererbungshierarchie soll es bei TPC Verbesserungen gegeben haben. Bisher war es so, dass nur einfache TPC-Szenarien möglich waren. Daran ändert sich auch nichts. Folgender Code lässt sich auch nicht mit der Version 4.3 mappen:


  public abstract class Product
  {
    public int Id { get; set; }

    [StringLength(50)]
    [Required]
    public string Name { get; set; }

    [StringLength(400)]
    public string Description { get; set; }
  }

  public class Book : Product
  {
    [StringLength(10)]
    [Required]
    public string ISBN10 { get; set; }

    [StringLength(13)]
    [Required]
    public string ISBN13 { get; set; }

    public int LanguageCD { get; set; }

    [Required]
    public int Pages { get; set; }
  }

  public class EBook : Book
  {
    [Required]
    public string Filename { get; set; }
  }

  public class Hardcover : Book
  {
    [StringLength(20)]
    [Required]
    public string Size { get; set; }

    [Required]
    public double Weight { get; set; }
  }

Im Designer ist dieser Variante auch nur über manuelle Anpassungen im EDMX-File möglich, aber es funktioniert.

Die Mapping Szenarien für Code First stehen auf der Website der .NET User Group Bern zur Verfügung, ein Update auf 4.3.1 muss aber noch gemacht werden. ;-) Bei mir sind die paar Tests auch mit EF 4.3.1 im grünen Bereich.

Abbildung 2 Mapping-Szenarien Tests mit EF 4.3.1
Abbildung 2

Translate this page

Kategorien