Wie soll ich eine gute Umgebung für .Net-Entwicklung für Sharepoint erstellen?

Ich mache derzeit MOSS-Entwicklung, und das Setup, das ich derzeit verwende, besteht aus einem einzigen Windows Server 2008 Standard-System (früher eine VM, jetzt ist es eine physische Maschine, aber ich habe keine persönliche Vorliebe für die eine oder andere Art) mit:

• Visual Studio 2008 Standard
• WSS 3 Visual Studio-Erweiterungen für 2008 ( Link )
• SmartPart-Vorlagen ( Link )
• Active Directory konfiguriert und eingerichtet mit einer eigenen Domäne
• Exchange konfiguriert und eingerichtet (sehr gut für den Zugriff auf die customAttributes in AD-Profilen, mit denen Sie Benutzerdaten verwalten und in SharePoint importieren können)
• WSPBuilder ( Link )
• SQL Server 2005 Standard

Hardware-mäßig läuft alles auf einem Dual-Core-2,5-Ghz-System mit 4 GB RAM - aber das Wichtigste ist, dass es ein 32-Bit-System ist, das muss deutlich betont werden. Ihre Entwicklungsumgebung muss 32bit sein, es gibt so viel in SharePoint, das unter 64bit gut läuft, aber Sie können nicht dagegen in 64bit entwickeln.

Ich betone das noch einmal - Sie müssen eine 32bit-Umgebung für die Entwicklung verwenden.

Nehmen Sie zum Schluss niemals eine Set-GUID für eine Dokumentbibliothek, eine Liste oder eine andere SharePoint-Funktion im Code an. Wenn Sie etwas auf eine bestimmte Art und Weise einrichten möchten, sollten Sie es in Ihr Bereitstellungsskript aufnehmen. Auf diese Weise wird der Verwaltungsaufwand für die Verwaltung der Entwicklungs-, UAT- und Produktionsumgebungen drastisch reduziert.

Das einzige, was ich an meinem aktuellen Setup ändern würde, ist das Verschieben des SQL Servers auf seine eigene Hardware, da dies den Overhead reduziert und Ihnen außerdem ermöglicht, das NTLM / Kerberos-Doppelsprungproblem in Bezug auf separate Dienste wie SQL Server zu untersuchen Reporting Services und der Geschäftsdatenkatalog.

Zusätzlich zu dem, was Lars sagt, empfehle ich Ihnen auch, die folgenden Umgebungen einzurichten:

1. Build - Verwenden Sie Continous Integration, um Ihre Anwendungen nach einem festgelegten Zeitplan zu kompilieren. Ich empfehle außerdem, Unit-Tests und Smoke-Tests als Teil Ihres Build-Prozesses auszuführen, um Ihren Build in einem bekannten Zustand zu halten.
2. Integrationstest - Verwenden Sie dies als Sandbox für die Entwicklungsteams, um sicherzustellen, dass alle Komponenten korrekt funktionieren. Betrachten Sie dies als eine Mini-Produktion. Ich empfehle, Builds mindestens einmal am Tag in diese Umgebung zu pushen, oder wenn du mit jedem guten Build aus der Build-Umgebung wirklich gut zurechtkommst.
3. QA - Dies ist eine dedizierte Sandbox für Ihre QA-Mitarbeiter. Hier sollten Builds nur gepusht werden, da Features für die Qualitätssicherung bereit sind.
4. Pre Production / UAT - Dies ist eine dedizierte Sandbox für SharePoint-Administratoren und -Kunden. Hier testen die SharePoint-Administratoren die Bereitstellungen und Kunden testen neue Funktionen und bieten die endgültige Abnahme vor der Produktion. Diese Umgebung sollte so virtualisiert werden, dass sie genau wie Produktion aussieht.

Sie sollten auf der SharePointDevWiki.com-Seite das Thema "Erstellen einer SharePoint-Entwicklungsumgebung" lesen. Link kann nicht eingefügt werden, da ich ein "neuer Benutzer" bin.