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

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

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

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

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

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

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

Пойдите по пути javascript.

Для этого нужно использовать файл Sharepoint Solution (WSP).

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

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

Разверните решение с помощью командной строки stsadm или через Central Site Admin.

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

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

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

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

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

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

Больше информации:

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

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

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