SharePoint ist nicht ganz wie, was Sie gewohnt sind. Meine zwei Hauptkritikpunkte sind:
Bereitstellung:
Wenn Ihre Anforderungen sind für eine einzige Produktionsstätte (keine Inszenierung/Test/Entwicklungsstandorte) Ihre beste Wette ist wahrscheinlich mit den SharePoint Designer zu gehen und Sachen hacken zusammen direkt auf der Produktionsstätte (ja, ich weiß, es ist schmutzig).
Wenn Sie diese anderen Umgebungen benötigen, sollten Sie Bereitstellungspakete für alles erstellen (keine xcopy-Bereitstellung). Deployment-Pakete sind ein PITA IMHO und sind sehr leicht falsch zu bekommen.
IIS
Sharepoint im Grunde über Ihre IIS Installation dauert und führt eine neue Reihe von Regeln für die, wo sich was befindet usw. Ein Gotcha ist „verwaisten“ Dateien. Wenn eine Datei mit dem SharePoint Designer geändert wird, wird die Datei in einer Datenbank gesichert, und von nun an verwendet IIS nur noch die Datei in der Datenbank. Es ist also nicht erforderlich, die Datei im Dateisystem zu ändern.
Fazit:
In meiner bescheidenen Meinung nach, wenn Sie eine Website machen, wo die Betriebszeit nicht so wichtig ist, und Sie können es sich leisten Fehler in der Produktion zu machen, kann Sharepoint mit dem Designer gut genug sein. Wenn Sie eine CMS Site erstellen, wo Sie den Code benötigen, um mehrere Umgebungen zu durchlaufen, bevor sie die Produktion erreicht (mit continuous integration), kann ich an kein anderes .NET-basiertes CMS denken, das eine schlechtere Arbeit leistet. Sie werden eine Menge Zeit verbringen, wie Sie die Bereitstellungsroutinen für Sie arbeiten, und Sie werden eine Menge Zeit mit Problemen im Zusammenhang mit "Ghosted" Dateien verbringen
Viel Glück.
Ist dies eine vorhandene SharePoint-Implementierung, der Sie Ihre benutzerdefinierten Formularfunktionen hinzufügen müssen, oder schlagen Sie vor, SharePoint als Entwicklungsplattform für Ihre Lösung zu verwenden? – webwires