Миграция решения с 2007 по 2010 год

Question

Допустим, у нас есть хорошо известное решение в Visual Studio 2008, используя WSPBuilder, чтобы объединить его в упаковку. Он имеет несколько функций и целый ряд активов для развертывания (.Webpart, .xsl, .js, изображения, столбцы сайта, типы контента и т. Д.) как в библиотеках, так и в 12 Hive.

Что бы вы предложили, чтобы подход был для перейти в 2010 год?

У меня есть странное ощущение, что папки SPI (такие же прекрасные, как и для управления элементами модуля) станут довольно занятыми и трудно управлять в решении VS2010 с несколькими функциями в одном проекте. Итак, вы бы все еще использовали WSPBUILDER и имеете в проекте свой 14/шаблон/функции/и т. Д.

Кроме того, мне ужасно не нравятся конструктивные поверхности «решения» и «функции», особенно если у вас есть решение VS2010 с несколькими проектами, каждый из которых имеет несколько функций.

У кого-нибудь еще есть опыт работы с решениями VS2010 среднего размера и вверх?

Также: предположение состоит в том, что решение 2010 года будет развернуто на ферме.

Answer 1

WSPBUILDER в CKS: Edition Edition Edition Edition для VS2010.http://cksdev.codeplex.com/

Пса Должен иметь это расширение для разработки SP.

Answer 2

Мы провели недавнюю миграцию с 2007 по 2010 год, средний проект (Silverlight Web -стороны, 30+ других веб -частей, WFC, Images, JS, определение списков, приемники и многое другое). Мы преобразовали все веб -части в визуальные веб -части (мы определили, что решение фермы в порядке), включая конвенции пространства имен. (Хотя пришлось воссоздать веб -части на страницах публикации). Мы также использовали способность папки карты SP VS2010 для добавления макетов, папок изображений. У нашего старого кода были жесткие каталоги с жестким кодированием, мы изменили их на использование 14 Hive через Appsettings. Также мы решили связать все в одной функции.

Я использую три расширения - SP Power Tools, Prodition Power Tools и PowerCommands для VS2010. Я больше не использую WSPBuilder, но использую встроенную функцию Deploy VS 2010. Довольно полезно.

Answer 3

Моя команда преобразовала большой проект SPS2007 WSP Builder в SharePoint 2010. Несколько важных вещей, которые следует запомнить, особенно если вы также обновляете базу данных SharePoint Content:

При воссоздании функций не забудьте использовать те же идентификаторы функций.

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

Не меняйте место развертывания для SharePoint Artifatcs. Если вы не хотите написать элементы обновления функций, определяющие новое местоположение необходимых файлов, может быть болезненным, если в большом проекте.

Используйте правильный элемент проекта SharePoint при воссоздании. Если нет, то конкретная функциональность может отсутствовать в Visual Studio для этого элемента проекта.

В большинстве случаев следующий рабочий процесс работает довольно хорошо. Создайте новый элемент WebPart в VS2010 -> Замените идентификаторы, файлы элементов и код из проекта WSP 2007 -> сделайте несколько настроек.

С CKS-DEV и VS2010 опыт разработки великолепен.

Answer 4

Я перенес решение с более чем одной функцией, и некоторые активы, развернутые в папке Mayouts с 2007 по 2010 год. Я был доволен опытом работы в Visual Studio 2010 после того, как привык к этому. Миграция была немного более ручной, чем я сначала ожидал, но в целом, не слишком сложной. Я рекомендую начать миграцию с помощью ящиков, чтобы помочь познакомиться с ними. Это может снизить вашу будущую зависимость от сторонних инструментов, которые могут не обновляться хорошо или поддерживаться, а также инструменты для поддерживаемых MS.

Answer 5

Смотрите нашу 4 серии части о Портирование решения SharePoint 2007 WSPBuilder в SharePoint 2010.