Разработка и развертывание сайта публикации SharePoint 2007

Question

Я новичок в SharePoint, и мне нужна помощь в запуске проекта. Я должен разработать издательский сайт, который будет доставлен клиенту. Я хотел бы предоставить клиенту опыт развертывания, который он получил бы при развертывании стандартного приложения ASP.NET, насколько это возможно. Я планирую использовать Visual Studio 2008 с расширениями SharePoint и, возможно, WSPBuilder или некоторыми другими инструментами. Мне также нужна помощь в структурировании всего проекта.

Вот что я планирую сделать:
1. Разработать минимальное определение сайта
2. Создать сайт из этого определения. Как я должен сделать это из кода? Использовать функцию SharePoint? Как мне его активировать?
3. Разработайте всю необходимую инфраструктуру для сайта (главную страницу, макеты, типы контента и т. Д.) В качестве компонентов SharePoint.

Правильно ли это, и как мне разработать все эти части, чтобы я мог создать какой-нибудь скрипт установки, чтобы клиент мог создать полный сайт одним щелчком мыши?

Answer 1

Определения сайтов - это сложный вопрос, но они очень полезны, если вам нужно развернуться в не связанных средах. Если вы находитесь на одной ферме серверов, возможно, определение сайта является излишним. Если вы переходите между доменами (т. Е. Test & prod, то, возможно, их стоит изучить).

Еще одно преимущество в определениях сайтов, особенно если доставка клиенту - это больше похоже на традиционную доставку. У них будет куча файлов (надеюсь, в управлении исходным кодом), которые являются их пользовательским сайтом. Я думаю, это дает ИТ-отделу гораздо теплее ощущение, чем XML-файл, созданный из пользовательского интерфейса SharePoint.

Еще одним преимуществом определений сайта является то, что вы имеете намного больший контроль над страницами, составляющими сайт. ИМХО, проще добавить главные страницы и пользовательский CSS с помощью определения шаблона сайта.

Мне любопытно, какие «движущиеся части» на сайте вы пытаетесь доставить? Я думаю, что ответ на этот вопрос определит, как определить структуру проекта.

В общем, я думаю, что вы на правильном пути. Особенности и решения являются обязательными. Я бы держался подальше от VSeWSS, он глючит, неуклюж и вообще ужасен, если вы пытаетесь сделать что-то сложное. Он пытается быть настолько умным, что не оставляет вам контроля.

Тем не менее, это действительно зависит от того, что вы пытаетесь сделать. Если вы собираетесь создать решение для развертывания в GAC с одной сборкой и использовать только те функции сборки, которые поддерживаются vsewss, у вас все будет в порядке.

Если, тем не менее, вы хотите разработать, скажем, разводку по заданию таймера, которая становится сложной в инфраструктуре функций VSeWSS. Также, если вам нужно несколько сборок в решении. YMMV, но мне пришлось выбросить его и найти более гибкое решение (привет NANT ).

Большая часть работы, которую вы в конечном итоге сделаете, - это создание, проверка и повторная проверка файлов конфигурации XML. Добавьте в справочную страницу Feature Schema на MSDN, вы потратите много времени на ее просмотр.

Наконец, да, если у вас есть все части, упакованные как функции, вы сможете разработать хороший скрипт установки. В конечном итоге сценарию потребуется вызвать команды STSADM (есть несколько действительно хороших расширений STSADM здесь ), необходимые для создания структуры сайта, добавления и развертывания решения и активации функций. Вы можете начать с командного файла, и получить как можно сложнее.

Answer 2

Я бы согласился с использованием готового определения сайта публикации, а затем его настройки с использованием функций семейства сайтов (главная страница, макеты страниц, CSS) и функций сайта (создание списков, страниц, подузлов, определение главного сайта). страницы сайтов и т.д ...).

Сшивание функций отлично подходит, когда вы хотите настроить новые сайты (разрешить пользователю создавать новые сайты) из хорошо известных шаблонов сайтов, например настроить внешний вид «Мой сайт». В этом случае я не думаю, что это очень полезно.

В качестве инструмента для решения этой задачи я лично использую STSDEV (http://www.codeplex.com/stsdev), чтобы помочь в создании, программировании, отладке и развертывании моих решений Sharepoint.

Сначала он создает хороший проект для Visual Studio (чистый или с некоторыми хорошими определениями "отправной точки"). Затем он включает в себя несколько «конфигураций сборки», которые действительно помогают при установке, развертывании и обновлении на компьютере разработчика.

Answer 3

Добавление другого ответа, потому что у меня есть более 300 символов, чтобы сказать: (

RE: Генератор решений SharePoint, еще раз, я бы сказал, ваш пробег может отличаться.

Самая большая проблема с SharePoint dev - это управление всеми «волшебными строками» в различных файлах конфигурации. Имена GUID и Fully Qualified Assembly - это то, что объединяет все это, и хотя все это имеет смысл, им очень трудно управлять.

Текущий набор инструментов все пытается облегчить сложность управления этими вещами, но они требуют, чтобы вы работали определенным образом, поэтому инструмент знает, как вводить соответствующую сантехнику.

Если вы планируете много работать с SharePoint, вам действительно следует научиться самостоятельно управлять системой. Это болезненно, но на самом деле приносит дивиденды.

По сути, я предлагаю вам потратить время на изучение платформы, а не инструментов. Как только вы узнаете платформу, использовать инструменты станет намного проще.

Если вы делаете это как одноразовое задание и просто хотите выполнить его, я уверен, что вы можете получить любой из инструментов, о которых вы упомянули, чтобы добиться цели.

Answer 4

Лично я не считаю, что создание определения сайта действительно полезно для сайтов, которые я создал. Их может быть очень сложно настроить из-за их сложной природы.

Я использую стандартный сайт публикации, а затем использую функции для добавления моих дополнительных компонентов (развернутых с помощью решения SharePoint).

Вы можете использовать функцию сшивания для подключения функции к созданию сайта публикации.

Я также только что сделал сообщение в блоге о том, как программно изменить рабочий процесс, который создается по умолчанию: http://www.aaron -powell.com / blog / feb февраля-2009 / программно-модифицирующий-sharepoint-workflows aspx (в комментариях также есть ссылка на концепцию сшивания объектов).

Затем я использую комбинацию установщика решений SharePoint (http://www.codeplex.com/sharepointinstaller) и пакетные файлы для установки компонентов. SSI для всех установок уровня базы данных SharePoint и пакетные файлы для файловой системы.