Продукт SharePoint от Microsoft сам по себе является весьма своеобразеным. Поэтому неудивительно, что разработка под SharePoint тоже требует определённых навыков. Например, программисту придётся стать еще и системным администратором, потому что без работы с группами/пользователями, правами доступа и т.п. не получится даже настроить среду и приступить к разработке. Хочется рассказать об одном этапе этой настройки среды — установке VSeWSS 1.3 — и о проблемах, с которыми пришлось столкнуться.

Некоторые из приведённых инструкций могут повлиять на безопасность и производительность SharePoint, поэтому должны применяться только в development-среде.

VSeWSS (Visual Studio 2008 extensions for Windows SharePoint Services) — это набор расширений Visual Studio (2008) для разработки под SharePoint. Этот набор содержит шаблоны проектов и средства, облегчающие отладку и deploying. Инструмен очень полезный, но при его настройке можно столкнуться со множеством неприятностей. Итак, вот проблемы, с которыми столкнулся я:

При установке появляется сообщение о проверке свободного места на диске

Есть известная проблема с некоторым семейством msi-инсталяторов. Суть проблемы в том, что при установке на виртуальную машину (в моём случае Virtual PC) программа не может осуществить проверку диска на предмет наличия свободного места. В результате пользователь видит сообщение:

Please wait while the installer finishes determining your disk space requirements

И это сообщение никогда не пропадает. VSeWSS как раз использует этот установщик. А так как SharePoint в целях разработки часто ставят на виртуальные машины с серверной операционкой, то проблема становится ещё актуальнее. Для её решения сначала нужно извлечь .msi-файл из имеющегося .exe (в моём случае VSeWSSv13_x86_Feb2009CTP_Build_429.exe). Это делается слудующей командой:

VSeWSSv13_x86_Feb2009CTP_Build_429.exe /extract content

После её выполнения в папке content находим файл VSeWSSv13_x86_Build-429.msi. Теперь нужно запустить этот файл так, чтобы диалог проверки места на диске не появлялся. Это делается командой:

msiexec /i VSeWSSv13_x86_Build-429.msi

Инсталятор молча сделает свою работу и первая проблема решена — VSeWSS успешно установлен!

Сообщение "The content type text/xml; charset=utf-8; of the response message.." при сборке

VSeWSS установлен — значит можно попробовать этот инструмент в деле. Открываем Visual Studio и создаём любой новый проект библиотеки SharePoint. Пытаемся собрать и получаем сообщение об ошибке:

System.ServiceModel.ProtocolException “The content type text/xml; charset=utf-8; of the response message does not match the content type of the binding (text/xml; charset=utf-8)”

Такое случается, если на сервере не корректно настроена работа WCF-сервисов (VSeWSS использует специальный сайт с WCF-сервисами для собственных нужд). Чтобы это исправить, нужно зарегистрировать в IIS расширения WCF. Делается это так:

cd "C:\WINDOWS\Microsoft.NET\Framework\v3.0\Windows Communication Foundation"
ServiceModelReg.exe -i

Если скрипт успешно отработал, то делаем iisreset и проблема исчезает.

Ошибка безопасности при сборке

При сборке проекта может появится ошибка безопасности. Сообщение может выглядеть так:

Error 1 VSeWSS Service Error: Error loading assembly [SOME PATH].dll.

VSeWSS Service Logging Error: Access to the path 'C:\Documents and Settings\Default User\Application Data\Microsoft\VSeWSS 1.3' is denied.

Logging failed attempting to write to C:\Documents and Settings\Default User\Application Data\Microsoft\VSeWSS 1.3\VSeWSS1.3 service.log. This may occur because the VSeWSS WCF Service does not have local administrator permissions. Please review the release notes.

Ошибка может быть вызвана попыткой доступа к какому-либо системному файлу (dll и т.п.) или собственному файлу внитри проекта. Появляется она из-за того, что уже упоминавшийся WCF-сервис, используемый VSeWSS, не наделён достаточными полномочиями для работы с файловой системой и другими ресурсами. Этот сервис хостится в специальном веб-приложении IIS. Называется приложение VSeWSS. Именно его (приложение) и нужно наделить соответствующими правами.

1. Если при установке VSeWSS не изменялся пул приложения сайта сервисов (по умолчанию используется пул SharePoint Central Administration v3), то пул приложения работает от имени пользователя Network Service. Можно добавить пользователя Network Service в группу Администраторы и проблема будет решена.
2. Можно назначить пулу SharePoint Central Administration v3 пользователя с админскими правами (например, свой собственный профиль). Это делается в Диспетчер сервера → Роли → Веб сервер (IIS) → Диспетчер служб IIS → Пулы приложений → выделяем SharePoint Central Administration v3 → жмём "Дополнительные параметры" → меняем поле "Удостоверение".
3. Можно создать для сайта VSeWSS в IIS специальный пул и/или специального пользователя, назначив соответствующие права.

Ошибка "Путь содержит недопустимые знаки"

Ещё одна ошибка, возникающая при сборке — Путь содержит недопустимые знаки. Почему-то VSeWss не дружит с кириллическими символами. Есть мнение, что пути к файлам проекта и к папке Temp не должны содержать этих символов, иначе VSeWss не будет работать. Я пытался вынести все файлы в «безопасную» папку, но ошибка не пропала. Сомое простое, что можно сделать — это создать в системе новый профиль, в имени которого нет кириллических символов, и вести всю работу под этим профилем.

После устранения названных ошибок мой проект успешно «собрался». Однако при запуске появилась новая ошибка:

Ошибка "Unable to start debugging on the web server. The web server is not configured correctly..." при запуске

Полный текст сообщения, появляющегося при запуске проекта:

Error (-1989080679) Unable to start debugging on the web server. The web server is not configured correctly. See help for common configuration errors. Running the web page outside of the debugger may provide further information.

Ошибка вызвана тем, что SharePoint не настроен для работы в режиме Debug. Для исправления нужно изменить web.config для SharePoint. Найти web.config можно примерно по такому пути:

C:\inetpub\wwwroot\wss\VirtualDirectories\80

Изменить нужно следующее (показаны только ключевые узлы):

<configuration>
  <SharePoint>
    <SafeMode CallStack="true" />
  </SharePoint>
  <!--...-->
  <system.web>
    <customErrors mode="Off" />
    <!--...-->
    <compilation debug="true" />
    <!--...-->
  </system.web>
</configuration>

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

Ошибка "Unable to start debugging on the web server. You do not have permissions to debug the web server process..." при запуске

Полный текст сообщения:

Error (-1989080679) Unable to start debugging on the web server. You do not have permissions to debug the web server process. You need to either be running as the same user account as the web server, or have administrative privilege.

Здесь всё решается совсем просто — достаточно запустить Visual Studio от имени администратора.

После устранения всех этих ошибок мой проект успешно запустился на Debug. Но при попытке интеграции собственных веб-частей в SharePoint вылетело исключение.

Security Exception при обращении к собственным веб-частям и другим классам

Ошибка появляется, когда собственный класс пытается взаимодействовать с SharePoint API. Полный текст сообщения:

Security Exception Description: The application attempted to perform an operation not allowed by the security policy. To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration file.

Exception Details: System.Security.SecurityException: Request for the permission of type 'Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' failed.

Как видно из текста, ошибка вызвана отсутствием прав на работу с API. В конфигурации SharePoint выставляется уровень доверия к сторонним сборкам. Если уровень доверия недостаточный, появляются подобные исключения. Чтобы исправить ситуацию можно пойти двумя путями:

1) просто выставить уровень Full для всех сборок.

2) VSeWSS при создаёт файл с описанием политики безопасности для собственных сборок (12/wss_custom_wss_minimaltrust.config). Но в его содержимом присутствует ошибка — к имени сборки добавляется лишнее ".dll":

$AppDirUrl$/bin/MyLib.dll.dll

Если удалять это ".dll", то всё будет нормально. Но это придётся делать каждый раз при сборке.