Изменение Системных Файлов SharePoint

Я сделал немного развития SharePoint, и я должен сказать вам, что возиться с 12-hive-это билет в мир боли, Если вы когда-нибудь захотите переместить приложение.

Я бы предпочел взломать некоторые javascript, чтобы скрыть его, по крайней мере, это может быть связано с главной страницей, которая намного более переносима.
И помните, вы никогда не знаете, когда появится следующий пакет обновления и уничтожит ваши изменения :)

Я согласен с Ларсом. Иногда вы не сможете избежать этого, в зависимости от ваших потребностей. Но, в целом, лучшая политика-избегать изменений, если это вообще возможно.

Я знаю, что некоторые другие пункты меню в меню текущего пользователя (изменить логин, Мои настройки и т. д.) могут быть изменены путем удаления разрешений у пользователя. В разделе Пользователи и группы есть опция для разрешений. Я не могу вспомнить точную настройку (разрабатывайте на работе, а не дома), но рядом с каждым из 30+ разрешений есть разумные описания. Удалите его, и вы начнете скрывать параметры меню. Никаких изменений в 12-hive не требуется.

Существует очень простое правило: если вы хотите сохранить официальную поддержку от Microsoft, не изменяйте ни один из файлов в 12 hive, которые установлены SharePoint.

Я никогда не сталкивался с ситуацией, когда единственным решением было изменить такой файл. Например, если вы хотите изменить пользовательский элемент управления out-of-the-box на SharePoint, вы можете сделать это, используя DelegateControl и переопределяя его в функции.

Дополнительная информация:

• http://msdn.microsoft.com/en-us/library/ms463169.aspx
• http://www.devx.com/enterprise/Article/36628

Я знаю, что это заманчиво быстро изменить файл, и я должен признать, что иногда я просто делаю это на коробке DEV, но не иду туда на рабочем сервере!

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

С точки зрения поддержки вам будет трудно для поддержки Microsoft (patches/hotfixes). С точки зрения технического обслуживания вы также открываете себя для долгосрочных затрат.

Идите по маршруту javascript.

Способ сделать это-использовать файл Sharepoint Solution (WSP).

Чтобы изменить пользовательский элемент управления, создайте новую функцию Sharepoint с новой функциональностью.

Включите эту функцию в свое решение.

Разверните решение либо с помощью командной строки stsadm, либо с помощью центра администрирования сайта.

Это будет автоматически развернуто на всех серверах в вашей ферме, и это позволит избежать перезаписи файлов sharepoint по умолчанию.

Для получения дополнительной информации, проверьте Sharepoint гайки и болты блог на http://www.sharepointnutsandbolts.com/ которые дают введение в WSP и Sharepoint функций.

Я делал это много раз, и я буду говорить по опыту: никогда не прикасайтесь к файлам onet.xml в пределах 12 hive ни при каких обстоятельствах. Любая ошибка, которую вы сделаете там, и чтобы сделать CAML еще более сложным, файл в значительной степени чувствителен к whitespace, будет иметь влияние на каждую часть SharePoint.

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

В большинстве случаев вы можете выполнить все, что хотите, используя функции и пакеты решений без изменения файлов. Однако есть несколько (довольно раздражающих) редких случаев, когда единственным вариантом было бы изменить файл в системе. Я использовал его для двух конкретных случаев до сих пор. Один из них должен был добавить PDF iFilter в файл docicon.xml, а другой-добавить тему в файл themes.xml. В обоих случаях это казалось единственным способом достижения цели. Тем не менее, мы использовали пакет решений для записи этих файлов на все серверы фермы.