Структуру своего первого SharePoint проекта я строил, руководствуясь принципами и практиками, которые я выработал, будучи ASP.NET разработчиком. Модульность, слабая связанность между частями проекта, точки агрегации зависимостей – все эти принципы так же удачно ложатся в основу структуры SharePoint проекта, как и в структуру большинства проектов созданных на основании других технологий. Если для вас эта тема нова или же хотите ее освежить, то я настоятельно рекомендую вам ознакомиться с серией статей Simon Ince посвященных созданию архитектуры на базе принципов заложенных в Microsoft Web Client Software Factory. В свое время они перевернули мое представление о том, как надо структурировать проекты.

Моя типичная структура одного модуля в ASP.NET проекте с backend-ом, скажем, в виде MS SQL базы данных выглядела следующим образом:

Думаю, что никого не удивил этой картинкой. Все как обычно: Repository формируется с учетом особенности базы данных, View завязывается на модель представления предлагаемую ASP.NET-ом, ну а Services (они же BLL) опираются лишь на интерфейсы торчащие из DAL и PL и ни на что конкретное не завязываются. В случае с  ASP.NET такая архитектура, в принципе, разворачивается без особых проблем – пара-тройка сервисов-фасадов для работы с HttpContext.Current и у нас полностью развязаны руки в BLL.

Но при попытке построить архитектуру SharePoint проекта по этим же принципам возникают некоторые трудности

В итоге, вместо, примерно, такой структуры:

У меня получилось вот это:

Иными словами: все слои приложения завязываются на модель SharePoint. При этом мы, разумеется, теряем всякую гибкость и жестко привязываемся всеми слоями к сущностям SharePoint. Жуть, не правда ли? Я долго и тщетно пытался все-таки скрыть от Services тот факт, что он работает с SharePoint. Но многочисленные фасады, адаптеры, прокси и прочие паттерны, которые я пытался применять, сильно замедляли процесс разработки и, в конечном счете, настолько усложняли код, что это делало его практически нечитаемым. Сейчас я остановился на мысли, что отвязаться от сущностей SharePoint на BLL не удастся, т.к. большая часть логики определяется структурой SharePoint и выполнения большей части операций приходится оперировать именно ими, а не Domain Model объектами, как это было в решениях, построенных на более легковесных платформах.

Ну, с архитектурными принципами, вроде бы более или менее определились, теперь, давайте более подробно остановимся на внутренней структуре моего текущего SharePoint проекта. Сразу оговорюсь – проект не очень большой – всего 3-4 модуля и 2 уровня их иерархии. Поэтому некоторыми из принципов я пренебрег в угоду простоты разработки и компактности решения. Вот, что у меня получилось:

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

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

• Complaints – SharePoint проект с представлениями. Здесь у нас находятся Controls, Application Pages, WebParts, EventReceivers(сами определения, но не их логика), Ribbons. Плюс здесь находятся Presenter-ы (я использую именно этот паттерн для разделения логики и представления). В процессе разработки этот модуль deploy-ится чаще всего.
• Complaints.Lists – SharePoint проект содержащий все, что связанно с уровнем хранения: Fields, Content Types, List Definitions и Instances. Обычно, заполняем его в самом начале и далее уже не трогаем.
• Complaints.Manager – самая обычная .NET сборка, deploy которой выполняется через обычное копирование в GAC (включена в пакет всех проектов, которые ее используют). По сути, это наша рабочая лошадка. Здесь находятся репозитории для работы со списками, сервисы с бизнес логикой, утилиты и всякие вспомогательные сущности.
• Complaints.Workflow – Ещё один SharePoint проект с рабочими процессами.

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

Common

В основе решения лежат 4 сборки с общими компонентами:

• Common.References – пустой проект, который разворачивает все сторонние сборки в GAC.
• Common.UI – проект с общими страницами и эл-тами управления (№ custom страница с сообщением об ошибке).
• Framework – проект с различными вспомогательными утилитами и базовыми классами, которые не относятся к предметной области.
• GlobalResources – ну, думаю, это из названия понятно.

Complaints

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

Complaints.Lists

Все сгруппировано по спискам. Там где есть необходимость – определены Custom формы. Они также построены с использованием паттерна MVP. Field-ы лежат в корне проекта.

Complaints.Manager

Пожалуй, самый интересный и сложный по своей структуре модуль.

• В Entities лежат различные вспомогательные DTO, которые, как правило, формируются в сервисах и передаются во View.
• Handlers – это своеобразные Presenter-ы для EventReceiver-ов. Они определяют какие сервисы и в каком порядке вызывать для обработки того или иного события.
• С Helpers, Resources и Services, думаю все понятно.
• Для каждого из списков имеется свой Repository, в который включены следующие файлы:
  • Entity – небольшой и абсолютно «плоский» DTO, который формируется вручную из SPListItem. Используется там, где-то нужно просто получить и отобразить.
  • Fields – набор строковых констант-имен полей.
  • ListDefinition – сущность, отображающая сам список. Содержит ряд вспомогательных методов для работы с  ним (но не с его элементами).
  • Repository – а это, непосредственно, сам репозиторий с CRUD методами для работы с элементами списка. Он абсолютно stateless, все, что нужно – приходит к нему в аргументах методов.

Модуль может зависеть только от других Manager-ов. Но это крайне нежелательно. В идеале – он автономен и зависит лишь от утилитарных сборок, вроде GlobalResources и Framework.

Complaint.Workflow

Тут ничего особенного. Просто определения рабочих процессов, из которых дергаются необходимые сервисы, определенные в ComplaintsManager.

Вот, что у нас в итоге получается в плане зависимостей между проектами модулями:

А вот схема зависимостей между модулями:

Архитектура не идеальная, но вполне жизнеспособная и расширяемая. При дальнейшем росте проекта и увеличении степени зацепления между модулями имеет смысл выделить интерфейсы сервисов и сущностей в отдельную сборку. Но тут надо быть аккуратным и не плодить сильно много SharePoint проектов – иначе замучаетесь ждать пока выполнится их deploy. Тему архитектуры проектов в SharePoint можно развивать и дальше, но, пожалуй, оставлю это на следующую статью. А сейчас жду ваших комментариев и предложений!

1. Используй виртуальную машину.
Сразу бери/проси машину помощнее, тебе понадобится, как минимум процессор i3/i5 и 8 gb памяти, чтобы поднять виртуальную машину в которой и будет вестись вся разработка. Работая в виртуальной среде, ты сэкономишь себе кучу времени и нервов, т.к. в случае чего – всегда можно откатиться к предыдущему snapshot-у, а при старте нового проекта восстановить исходное состояние системы с чистым SharePoint всего за пару кликов. Ну а если разработка ведется сразу в двух ветках одного проекта (скажем, branch с фиксами для прошлого релиза и trunk с новой функциональностью), то без возможности переключаться между snapshot-ами просто никак. Выбор платформы остается за тобой, но я, лично, предпочитаю связку VMWare + Windows 2008 R2.

2. Выработай четкую политику накатывания обновлений.
С webpart-ами, формами и т.п. у тебя не должно возникнуть никаких проблем при накатывании новых изменений, т.к. при их re-deploy ты ничего не потеряешь, но вот с полями, типами, списками и рабочими процессами тебе придется помучиться. Постарайся четко определиться (а ещё лучше как-то автоматизировать) каким образом ты будешь накатывать изменения на production сервер. Я для себя выбрал следующую тактику: при внесении какого-либо изменения в схему списка или контентного типа тут же создается PowerShell скрипт, позволяющий накатить те же самые изменения на предыдущий релиз, развернутый у заказчика и на тестовом сервере. Скрипты упорядочиваются по задачам, к которым они привязаны и номерам версий. Feature Upgrade, конечно более естественный для SharePoint механизм накатывания изменений на схему, но у меня с ним возникала куча самых разных проблем.

3. Нет, от конетекста SharePoint тебе не отвязаться.
Поначалу я очень-очень старался скрыть от слоя бизнес-логики тот факт, что (о ужас!) она взаимодействует с SharePoint. Подсовывал всякие DTO и DataModel объекты, генерировал фасады и медиаторы, сервисы-провайдеры и репозитории. Но все это бесполезно, не тратьте впустую время – ты работаешь с SharePoint, так что изволь играть по его правилам. Передавай SPListItem-ы в сервисы уровня BLL, которые отвечают за назначения прав доступа, прокидывай SPWeb сквозь View в Presenter и далее в Model. Да – некрасиво, да – очень сложно тестировать. Но иначе ты просто рискуешь запутаться из какого контекста пришел тот или иной объект (страница/ресивер/таймер) и увязнуть в тонне фасадов, созданных на каждый случай. Улучшай читаемость, степень повторного использования кода внедряй модные паттерны и разделяй на слои, но делай это все в духе SharePoint.

4. Разделяй и властвуй.
Советую сразу выделять все, что связано с уровнем хранения данных (поля, типы, списки) в отдельные проекты. Это существенно упростит процесс deploy и отладки. Рабочие процессы, кстати, тоже по-хорошему надо выносить в отдельный пакет.

5. EventReciver-ы не так просты, как кажутся.
Если у тебя есть задача, которая решается при помощи EventReceiver-ов и это твоя первая встреча с ними – не торопись. Они только с виду кажутся простыми, а на практике с ними столько заморочек. Лучше сядь, прочитай главу про EventReceiver-ы в какой-нибудь умной книжке (мне, кстати, нравится Jorg Krause – SharePoint 2010 as a Development Platform (amazon)) и серию из двух статей в блоге gandjustas-а (часть 1, часть 2). А затем определить какой именно из Receiver -ов тебе нужен, и не спеша, вдумчиво приступай к реализации. Я в свое время потратил кучу времени и нервов, пытаясь с ходу реализовать сложный Receiver.

6. Использовать Linq To SharePoint не самая лучшая идея.
Я вот тоже очень обрадовался, когда узнал, что в SharePoint 2010 теперь есть настоящий Linq для работы со списками. Сразу же кинулся все на нем реализовывать и только потом понял, что зря я это сделал. Linq2SP предоставляет очень скудную функциональность по работе со списками. Если ты реализуешь что-то, действительно, серьезное, то почти наверняка придется плодить параллельную иерархию на основе объектной модели SharePoint (SPListItem, CAML и т.п.). А дублирование кода никогда ни к чему хорошему не приводило. Плюс, к тому же, ты его никак не контролируешь и из-за этого можно очень легко накосячить с производительностью. Но если все-таки хочется чего-то Linq-ушного, то бери на вооружение Camlex. Вещь неплохая, хорошо встраивается в существующие SharePoint проекты, да и к тому же он OpenSource.

7. Есть много плагинов и приложений, которые упрощают работу с SharePoint.
SharePoint Software Factory – сборник “рецептов” и полезных утилит для работы с SharePoint. Особенно советую обратить внимание на возможность копирования файлов напрямую в GAC/Hive, минуя deploy (неплохо экономит время) и на attach к процессам SharePoint(IIS, Timer) для отладки.
CKS – Development Tools Edition - почти тоже, что и Software Factory, но без рецептов.
ULS Viewer – утилита для работы с логами SharePoint. Он там пишет очень много всего интересного. В случае возникновения непонятной ошибки в первую очередь советую заглянуть именно туда.
SharePoint Manager 2010 – Невероятно полезная утилита. Позволяет посмотреть структуру сайтов SharePoint и получить схемы всего и вся. Много раз выручал меня.
U2U Caml Query Builder – Утилита для построения CAML запросов. Удобно, просто, наглядно.
SPDisposeCheck – Проверяет проекты на предмет утечки памяти. Запускай время от времени, а ещё лучше, интегрируй в свой Continuous Integration сервер.

8. PowerShell твой лучший друг.
Серьезно, не пренебрегай им. На PowerShell очень просто писать патчи для обновления схем и небольшие утилиты для автоматизации каких-либо действий. В качестве IDE я советую использовать PowerGUI.

9. Не забывай освобождать ресурсы.
Надеюсь, ты уже в курсе, что часть SharePoint реализовано с использованием COM, и что такие объекты как SPSite и SPWeb тянут за собой неуправляемые ресурсы, которые надо явно высвобождать через Dispose? Вот я когда-то не знал и очень удивлялся, когда через день активной работы SharePoint забирал себе всю память, и ни в какую не хотел ее отдавать назад. Так что следи за каждым созданием SPSite и SPWeb, прочитай эту статью на MSDN и время от времени запускай SPDisposeCheck (см. п.7).

10. SharePoint с налету не взять.
Когда мне предложили попробовать себя в роли SharePoint разработчика я подумал: “Хм, а почему бы и нет? Я вроде бы поднаторел в изучении новых платформ. IPhone и Flex пошли на “ура”. А SharePoint, это всего-навсего надстройка над ASP.NET. Легко!”. Как окажется позднее – я сильно ошибался, SharePoint с налету не взять. Будь сразу готов к тому, что у разработчиков SharePoint было свое мнение по поводу того, что логично, а что нет. Тебе придется потратить кучу времени, раскапывая тонны javascript-ов и xml-ек, чтобы разобраться, как добавить одну единственную кнопку, без которой заказчик не хочет принимать форму. Для меня SharePoint это один большой Challenge. Читай книжки, блоги, выискивай статьи на msdn, общайся на форумах и будь готов к сложностям. Впрочем, как раз из-за обилия этих сложностей нам хорошо платят и мы нужны всем.

Буду очень рад, если кто-то захочет дополнить этот список и поделиться своим опытом работы с SharePoint. Пишите, комментируйте!

* – хотя, корректнее, было бы сказать мыслей или знаний полученных в результате практической работы с SharePoint.

Как я провел лето (или мысли разработчика о SharePoint)

Microsoft SharePoint 2010 Server представленный корпорацией Microsoft является ничем иным, как очень мощным инструментов для построения документо-оринетированных систем. Но эта “мощность” SharePoint, как платформы носит двуликий характер: с одной стороны, он предоставляет широкий спектр инструментов и функций для работы с документами (и другими абстракциями описанными в рамках системы), но с другой стороны – разработчику крайне тяжело(а, порою, и вовсе невозможно) менять абстракции и процессы лежащие в основе платформы.

С точки зрения разработчика

Модель предметной области

Microsoft SharePoint полностью инкапсулирует слой работы с SQL базой данных от разработчика, предоставляя свой набор базовых абстракций (поле, контентный тип, определение и экземпляр списка/документа) и инструментов (LinqToSharePoint, CAML, объектная модель) для взаимодействия с уровнем доступа к данным (DAL). Данный подход существенно упрощает создание новых сущностей предметной области, т.к. основные типы и абстракции уже описаны в системе. Так для создания нового типа документа обладающего стандартным набором атрибутов (Имя, Автор, Дата создания, и т.п.) достаточно воспользоваться предопределенным контентным типом “Документ”, который уже содержит необходимый набор атрибутов. SharePoint так же предоставляет удобные графические инструменты для формирования и редактирования сущностей уровня хранения данных.

Но, помимо вышеперечисленных преимуществ, данный подход обладает множеством недостатков.  Прежде всего, стоит отметить, что большинство разработчиков привыкли использовать в качестве хранилища данных реляционную СУБД. В этой области наработано огромное количество теоретического материала, практик и инструментов, которые существенно упрощают разработку системы, делая её прогнозируемым, сходящимся процессом. Подход к хранению данных, используемый в SharePoint почти полностью исключает возможность использования существующих практик. Остановимся более подробно на особенностях DAL в SharePoint:

Поля

SharePoint обладает весьма скудным набором типов полей, и при этом они определены на довольно-таки высоком уровне (по сравнению с базовыми типами, предоставляемыми реляционными базами данных). Такой подход существенно усложняет проверку корректности данных на уровне хранения. При работе с SQL сервером, к примеру, можно легко указать диапазон допустимых значений для того или иного поля. В Microsoft SharePoint предусмотрен механизм расширения набора типов полей, но он является весьма нетривиальным и плохо документированным. Помимо этого, все проверки осуществляются в управляемом коде, а не в базе данных, что при работе с большими объемами данных может крайне негативно сказаться на производительности системы.

Типы и списки

В роли аналогов таблиц реляционных СУБД в SharePoint выступают контентные типы и списки. Этот подход позволяет использовать некоторые концепции объектно-ориентированного программирования при проектировании уровня хранения данных. Но при этом утрачивается вся та гибкость в проектировании и оптимизации структур данных, которая возможна была с реляционной СУБД. Так же, в SharePoint имеются существенные проблемы с объемами хранимых данных (Microsoft не советует хранить более 5000 элементов в списке, что абсолютно неприемлемо для большинства задач. Решения этой проблемы существуют, но они требуют дополнительных трудозатрат и ведут к запутыванию логики приложения). И, на конец, SharePoint не поддерживает транзакционных операций при работе со списками и документами.

Выборка данных

SharePoint предоставляет несколько инструментов для получения данных с уровня хранилища. Но ни одно из них не обладает той производительностью и гибкостью, которую способна обеспечить реляционная база данных через SQL запрос или хранимую процедуру. LinqToSharePoint является очень сырым и ограниченным инструментом (низкая скорость, узкий спектр поддерживаемых операций для выборки данных, сложность в генерации модели, отсутствие точек расширения и т.д.). CAML, в отличие от LinqToSharePoint, более приспособлен к работе с абстракциями SharePoint, но при этом он абсолютно нетипизирован и довольно-таки сложен в плане динамического построения запросов.

Точки доступа

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

Изменение схемы хранения данных

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

Процесс разработки

Тестирование

Процесс тестирования системы написанной на базе платформы SharePoint существенно затруднен по сравнению с тестированием системы созданной на базе ASP.NET. Крайне сложно (а, порою, и вовсе невозможно) обеспечить идентичное состояние системы на тестовом сервере, сервере заказчика и машине разработчика. Автоматическое Unit-тестирование так же затруднено из-за того, что каждый запуск и выполнение теста может занимать до нескольких минут. Это делает почти невозможным использование таких практик, как Test Driven Development, которые могли бы существенно повысить качество разрабатываемого кода и снизить издержки на ручное тестирование.

Отладка

Одним из преимуществ современных сред разработки является возможность удобной отладки кода. При разработке на SharePoint почти все преимущества в отладке приложения сходят на нет. Каждое подключение к серверу в режиме отладки, как и в случае с тестами, может занимать до нескольких минут. Такое состояние дел превращает процесс отлаживания кода приложения в затянутый и скучный процесс, который разработчики стараются избегать, что, в свою очередь, ведет к снижению качества кода. Так же, стоит отметить систему логирования SharePoint. Это весьма мощный инструмент для диагностирования ошибок, но для его эффективного использования необходимо применять сторонние утилиты (ULSViewer).

Рабочее место

Не смотря на существенный прогресс в интеграции средств разработки SharePoint в Microsoft Visual Studio 2010 и в возможности разворачивания сервера на клиентской операционной системе (Microsoft Windows 7 x64), организация “комфортного” рабочего места разработчика по прежнему остается нетривиальной задачей. Прежде всего, для одновременной работ в Visual Studio и SharePoint Server рабочая машина должна быть оснащена мощным процессором и большим (6-8 gb) объемом оперативной памяти. Разработка на общим, выделенном сервере невозможна из-за необходимости в постоянных перезагрузках IIS сервера. Наиболее рациональным видится решение с организацией рабочего места в рамках виртуальной машины. Это позволит существенно сократить время на переустановку системы в случае, если SharePoint перестанет работать (такая ситуация довольно-таки часто возникает на машине разработчика и в ряде случаев исправляется лишь полной переустановкой операционной системы).

Концепции и структура

Отличительной чертой хорошо спроектированного приложения является четкая структура и соблюдение архитектурных концепций на всех его уровнях и во всех модулях. В классическом подходе привычном большинству разработчиков в архитектуре приложения явно выделяется три слоя: слой хранения данных, бизнес логики и представления. Как уже упоминалось ранее, в SharePoint сложно явно выделить слой работы с данными, т.к. в зависимости от текущего контекста (страница, обработчик события, рабочий процесс, и т.д.) варьируется способ доступа и изменения данных. Можно построить свой ORM(платформа и рынок не предоставляет готовых библиотек), но для решения ряда задач в рамках системы придется отходить от него, что только запутает архитектуру. То есть, классический подход к проектированию информационных систем не применим по отношению к SharePoint. Есть предположение, что каждая часть, каждый модуль должен выступать в качестве самостоятельной под-системы. Чем меньше будет общих абстракций и слоев – тем проще будет обеспечить работоспособность и производительность каждого модуля и всей системы в целом. При этом, разумеется, увеличивается время и сложность поддержки системы.

Итого

Вне всякого сомнения, Microsoft SharePoint 2010 является крайне мощной платформой для построения бизнес-ориентированных систем, включающей в себя огромное число самых разнообразных компонент. Но при этом порог вхождения в разработку на этой платформе очень велик (по сравнению с классическим ASP.NET). Это обусловлено плохой документированностью функциональности, не очень удачной архитектурой существенно затрудняющей внесение изменений и чрезмерной внутренней сложностью. Любая команда, сколь опытной она бы ни была – почти наверняка столкнется с серьезными трудностями при разработке их первого приложения на базе  Microsoft SharePoint. Большинство практик, библиотек и методик, гарантировавших успех и качество проекта при разработке на ASP.NET (или любом другом низкоуровневом framework-е)  в случае с SharePoint не только могут оказаться бесполезными, но так же могут нанести “вред” разработке из-за того, что они изначально спроектированы для работы с совсем иным уровнем абстракций, нежели тот, что предоставляет SharePoint.

P.S. Все выше сказанное – это мое мнение, как разработчика, которое сложилось за 9 месяцев участия в проекте разрабатываемом на Microsoft SharePoint 2010.  Не смотря на то, что за это время мне пришлось очень плотно работать с платформой, я по прежнему не могу сказать, что понимаю, как именно нужно правильно разрабатывать приложения на SharePoint. Буду крайне признателен за конструктивную критику.

Сегодня я хотел бы написать об улучшенной версии. Методы были подвергнуты тотальному рефакторингу + добавилась возможность явно указывать домен в котором будут производиться манипуляции над группами.

1. Создание доменной группы:

const string GroupSchemaClassName = "group";

/// <summary>
/// Типы доменных групп.
/// </summary>
[Flags]
enum DomainGroupTypes : uint
{
    UniversalGroup = 0x08,
    DomainLocalGroup = 0x04,
    GlobalGroup = 0x02,
    SecurityGroup = 0x80000000
}

/// <summary>
/// Создать новую группу в домене.
/// </summary>
/// <param name="domain">Имя домена в котором будет создана группа.</param>
/// <param name="name">Имя создаваемой группы.</param>
/// <param name="description">Описание группы, которое будет отображаться в поле "Description".</param>
void CreateDomainGroup(string domain, string name, string description)
{
	//Получение DirectoryEntry для указанного домена.
	var root = DomainUtil.GetDomainDirectoryEntry(domain);

	root = root.Children.Find("CN=Users");

	using (var group = root.Children.Add(string.Format("CN={0}", name), GroupSchemaClassName))
	{
		group.Properties["sAMAccountName"].Add(name);
		group.Properties["description"].Add(description);

		//Можете варьировать тип группы как вам нужно через операцию "|" (побитовое или)
		DomainGroupTypes groupType = DomainGroupTypes.DomainLocalGroup | DomainGroupTypes.SecurityGroup;

		group.Properties["groupType"].Add((int) groupType);

		group.CommitChanges();
	}
}

2. Создание локальной группы

/// <summary>
/// Создать новую группу на текущей машине.
/// </summary>
/// <param name="name">Имя создаваемой группы.</param>
/// <param name="description">Описание группы, которое будет отображаться в поле "Description".</param>
void CreateLocalGroup(string name, string description)
{
	var root = new DirectoryEntry(string.Format("WinNT://{0},computer", Environment.MachineName));

	using (var group = root.Children.Add(name, GroupSchemaClassName))
	{
		group.Invoke("Put", new object[] {"description", description});

		group.CommitChanges();
	}
}

3. Проверка, существует ли группа с указанным именем в некотором домене.

[/// <summary>
/// Проверить, существует ли группа с указанным именем в домене или нет.
/// </summary>
/// <param name="domain">Домен в котором осуществляется поиск группы.</param>
/// <param name="name">Имя искомой группы.</param>
/// <returns>"true" если группа существует, иначе - "false".</returns>
bool IsDomainGroupExists(string domain, string name)
{
	try
	{
		var result = GetDomainGroupSid(domain, name);
		return result != null;
	}
	catch (DirectoryServicesCOMException e)
	{
		//There is no such object in the server.
		if (e.ErrorCode == -2147016656)
			return false;

		throw;
	}
}

4. Проверка, существует ли группа с указанным именем на локальной машине.

/// <summary>
/// Проверить, существует ли группа с указанным именем на локальной машине или нет.
/// </summary>
/// <param name="name">Имя искомой группы.</param>
/// <returns>"true" если группа существует, иначе - "false".</returns>
bool IsLocalGroupExists(string name)
{
	try
	{
		var result = GetLocalGroupSid(name);
		return result != null;
	}
	catch (COMException e)
	{
		//There is no such object in the server.
		if (e.ErrorCode == -2147022676)
			return false;

		throw;
	}
}

5. Получение SID (Security IDentifier) доменной группы:

/// <summary>
/// Получение SID-а доменной группы.
/// </summary>
/// <param name="domain">Домен в котором осуществляется поиск группы.</param>
/// <param name="name">Имя искомой группы.</param>
/// <returns>SID доменной группы.</returns>
SecurityIdentifier GetDomainGroupSid(string domain, string name)
{
	try
	{
		var result = DomainUtil.GetDomainIdentitySid(domain, name, GroupSchemaClassName);
		return result;
	}
	catch (DirectoryServicesCOMException e)
	{
		//There is no such object in the server.
		if (e.ErrorCode == -2147016656)
			return null;

		throw;
	}
}

6. Получение SID-а локальной группы:

/// <summary>
/// Получение SID-а локальной группы.
/// </summary>
/// <param name="name">Имя искомой группы.</param>
/// <returns>SID доменной группы.</returns>
SecurityIdentifier GetLocalGroupSid(string name)
{
	try
	{
		return LocalUtil.GetLocalIdentitySid(name, GroupSchemaClassName);
	}
	catch (COMException e)
	{
		//There is no such object in the server.
		if (e.ErrorCode == -2147022676)
			return null;

		throw;
	}
}

+В выше описанном коде так же встречается два вспомогательных класса DomainUtil и LocalUtil с функциями для получения SID-а сущности:

static class DomainUtil
{
	/// <summary>
	/// Получение SID-а доменной сущности.
	/// </summary>
	/// <param name="domain">Имя домена.</param>
	/// <param name="name">Имя сущности.</param>
	/// <param name="schemaClassName">Тип сущности.</param>
	/// <returns>SID доменной сущности, если она существует. В противном случае null.</returns>
	public static SecurityIdentifier GetDomainIdentitySid(string domain, string name, string schemaClassName)
	{
		var root = GetDomainDirectoryEntry(domain);
		root = root.Children.Find("CN=Users");

		foreach (DirectoryEntry entry in root.Children)
		{

			if (!string.Equals(entry.SchemaClassName, schemaClassName, StringComparison.OrdinalIgnoreCase))
				continue;

			var entiryName = entry.Properties["sAMAccountName"][0].ToString();
			if (string.Equals(entiryName, name, StringComparison.OrdinalIgnoreCase))
			{
				var sid = new SecurityIdentifier((byte[])entry.Properties["objectSid"].Value, 0);
				return sid;
			}
		}

		return null;
	}

	/// <summary>
	/// Вспомогательная функция для получения корня домена.
	/// </summary>
	private static DirectoryEntry GetDomainDirectoryEntry(string domain)
	{
		var path = string.Format("LDAP://{0}", domain);
		return new DirectoryEntry(path);
	}
}

static class LocalUtil
{
	/// <summary>
	/// Получение SID-а локальной сущности.
	/// </summary>
	/// <param name="name">Имя сущности.</param>
	/// <param name="schemaClassName">Тип сущности.</param>
	/// <returns>SID локальной сущности</returns>
	public static SecurityIdentifier GetLocalIdentitySid(string name, string schemaClassName)
	{
		var root = new DirectoryEntry(string.Format("WinNT://{0},computer", Environment.MachineName));

		var entry = root.Children.Find(name, schemaClassName);

		var sid = new SecurityIdentifier((byte[]) entry.Properties["objectSid"].Value, 0);
		return sid;
	}
}

(Скачать)

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

Platform GetApplicationPlatform()
{
	switch (IntPtr.Size)
	{
		case 4:
			return Platform.X86;
		case 8:
			return Platform.X64;
		default:
			return Platform.Unknown;
	}
}

Оно основывается на том факте, что на 32-х битных платформах размер указателя(IntPtr) равен 4-м байтам (или 32 битам), в то время как на 64-х битной платформе он равен 8-ми. Тем не менее, у данного решения есть один существенный недостаток – оно работает лишь в том случае, если вы при компиляции приложения указали значение параметра «Solution Platform» как «Any CPU» (это позволяет JIT-компилятору самостоятельно выбирать размерность адресного пространства в зависимости от текущей платформы).

Существует и более универсальное решение, которое будет работать вне зависимости от значения параметра «Solution Platform». Оно заключается в вызове WinAPI функций GetNativeSystemInfo и GetSystemInfo. Первая используется для OS семейства Windows основанных на ядре NT 5.1 или старше (начиная от Windows XP), вторая – для более ранних версий.

const ushort PROCESSOR_ARCHITECTURE_INTEL = 0;
const ushort PROCESSOR_ARCHITECTURE_IA64 = 6;
const ushort PROCESSOR_ARCHITECTURE_AMD64 = 9;
const ushort PROCESSOR_ARCHITECTURE_UNKNOWN = 0xFFFF;

[StructLayout(LayoutKind.Sequential)]
struct SYSTEM_INFO
{
	public ushort wProcessorArchitecture;
	public ushort wReserved;
	public uint dwPageSize;
	public IntPtr lpMinimumApplicationAddress;
	public IntPtr lpMaximumApplicationAddress;
	public UIntPtr dwActiveProcessorMask;
	public uint dwNumberOfProcessors;
	public uint dwProcessorType;
	public uint dwAllocationGranularity;
	public ushort wProcessorLevel;
	public ushort wProcessorRevision;
};

[DllImport("kernel32.dll")]
static extern void GetNativeSystemInfo(ref SYSTEM_INFO lpSystemInfo);

[DllImport("kernel32.dll")]
static extern void GetSystemInfo(ref SYSTEM_INFO lpSystemInfo);

Platform GetOperationSystemPlatform()
{
	var sysInfo = new SYSTEM_INFO();

	// Если WinXP или старше - используем GetNativeSystemInfo
	if (Environment.OSVersion.Version.Major > 5 ||
		(Environment.OSVersion.Version.Major == 5 && Environment.OSVersion.Version.Minor >= 1))
	{
		GetNativeSystemInfo(ref sysInfo);
	}
	// Иначе используем GetSystemInfo
	else
	{
		GetSystemInfo(ref sysInfo);
	}

	switch (sysInfo.wProcessorArchitecture)
	{
		case PROCESSOR_ARCHITECTURE_IA64:
		case PROCESSOR_ARCHITECTURE_AMD64:
			return Platform.X64;

		case PROCESSOR_ARCHITECTURE_INTEL:
			return Platform.X86;

		default:
			return Platform.Unknown;
	}
}

P.S. Platform – простой enum, со следующими значениями:

enum Platform
    {
        X86,
        X64,
        Unknown
    }

1. Создание пользователя.
2. Создание группы.
3. Добавление пользователя в группу.
4. Проверка, существует ли группа с заданным именем.
5. Проверка, является ли пользователь членом группы.

(Скачать)

1. Создание пользователя:

public static void CreateLocalUser(string login, string fullName, string password)
{
    var root = new DirectoryEntry(string.Format("WinNT://{0},computer", Environment.MachineName));
    using (var user = root.Children.Add(login, "user"))
    {
        user.Properties["FullName"].Value = fullName;
        user.Invoke("SetPassword", new object[] { password });
        user.CommitChanges();
    }
}

2. Создание группы:

public static void CreateLocalGroup(string name, string description)
{
    var root = new DirectoryEntry(string.Format("WinNT://{0},computer", Environment.MachineName));
    using (var group = root.Children.Add(name, "group"))
    {
        group.Invoke("Put", new object[] {"description", description});
        group.CommitChanges();
    }
}

3. Добавление пользователя в группу:

public static void AddLocalUserToLocalGroup(string userName, string groupName)
{
    string groupPath = string.Format("WinNT://{0}/{1},group", Environment.MachineName, groupName);
    string userPath = string.Format("WinNT://{0}/{1},user", Environment.MachineName, userName);
    var root = new DirectoryEntry(groupPath);
    root.Invoke("Add", new object[] { userPath });
    root.CommitChanges();
}

4. Проверка, существует ли группа с заданным именем:

public static bool IsLocalGroupExists(string name)
{
    var root = new DirectoryEntry(string.Format("WinNT://{0},computer", Environment.MachineName));
    try
    {
        root.Children.Find(name, "group");
        return true;
    }
    catch (COMException e)
    {
        if (e.ErrorCode == -2147022676)
            return false;
        throw;
    }
}

5. Проверка, является ли пользователь членом группы:

public static bool IsUserInLocalGroup(string userName, string groupName)
{
    var root = new DirectoryEntry(string.Format("WinNT://{0},computer", Environment.MachineName));
    root = root.Children.Find(userName, "user");
    var groups = root.Invoke("groups");
    foreach (var group in (IEnumerable) groups)
    {
        var groupEntry = new DirectoryEntry(group);
        if (string.Equals(groupEntry.Name, groupName, StringComparison.CurrentCultureIgnoreCase))
            return true;
    }
    return false;
}

1. Создание пользователя.
2. Создание группы.
3. Добавление пользователя в группу.
4. Проверка, существует ли группа с заданным именем.
5. Проверка, является ли пользователь членом группы.
+ Флаги, описывающие тип доменной группы.
+ Флаги, описывающие параметры пользователя.

(Скачать)

1. Создание пользователя:

public static void CreateDomainUser(string login, string fullName, string password)
{
    string domainDNS = Domain.GetComputerDomain().ToString();
    var root = Domain.GetComputerDomain().GetDirectoryEntry();
    root = root.Children.Find("CN=Users");
    string cn = string.IsNullOrEmpty(fullName) ? login : fullName;
    using (var user = root.Children.Add(string.Format("CN={0}", cn), "user"))
    {
        user.Properties["sAMAccountName"].Value = login;
        string upn = string.Format("{0}@{1}", login, domainDNS);
        user.Properties["userPrincipalName"].Value = upn;
        user.CommitChanges();
        user.Invoke("SetPassword", new object[] { password });
        user.Properties["userAccountControl"].Value = AdsUserFlags.NormalAccount | AdsUserFlags.PasswordDoesNotExpire;
        user.CommitChanges();
    }
 }

2. Создание группы:

public static void CreateDomainGroup(string name, string description, DomainGroupTypes groupTypes)
{
    var root = Domain.GetComputerDomain().GetDirectoryEntry();
    root = root.Children.Find("CN=Users");
    using (var group = root.Children.Add(string.Format("CN={0}", name), "group"))
    {
        group.Properties["sAMAccountName"].Add(name);
        group.Properties["description"].Add(description);
        group.Properties["groupType"].Add((int) groupTypes);
        group.CommitChanges();
    }
}

3. Добавление пользователя в группу:

public static void AddDomainUserToDomainGroup(string userName, string groupName)
{
    string domainDNS = Domain.GetComputerDomain().ToString();
    var root = Domain.GetComputerDomain().GetDirectoryEntry();
    root = root.Children.Find("CN=Users");
    var group = root.Children.Find(string.Format("CN={0}", groupName), "group");
    var user = root.Children.Find(string.Format("CN={0}", userName), "user");
    group.Properties["member"].Add(user.Path.Substring(7 + domainDNS.Length + 1));
    group.CommitChanges();
}

 
4. Проверка, существует ли группа с заданным именем:

public static bool IsDomainGroupExists(string name)
{
    var root = Domain.GetComputerDomain().GetDirectoryEntry();
    root = root.Children.Find("CN=Users");
    try
    {
        root.Children.Find(string.Format("CN={0}", name), "group");
        return true;
    }
    catch (DirectoryServicesCOMException e)
    {
        if (e.ErrorCode == -2147016656)
            return false;
        throw;
    }
}

5. Проверка, является ли пользователь членом группы:

public static bool IsUserInDomainGroup(string userName, string groupName)
{
    var root = Domain.GetComputerDomain().GetDirectoryEntry();
    var searcher = new DirectorySearcher(root)
                       {
                           Filter = string.Format("sAMAccountName={0}", userName)
                       };
    searcher.PropertiesToLoad.Add("memberOf");
    SearchResult result = searcher.FindOne();
    if (result != null)
    {
        var groups = result.Properties["memberOf"];
        foreach (var group in groups)
        {
            string entry = group.ToString();
            entry = entry.Substring(0, entry.IndexOf(",", 0));
            entry = entry.Replace("CN=", string.Empty);
            entry = entry.Trim();
            if (string.Equals(entry, groupName, StringComparison.CurrentCultureIgnoreCase))
                return true;
        }
    }
    return false;
}

+ Флаги, описывающие тип доменной группы:

[Flags]
public enum DomainGroupTypes : uint
{
    UniversalGroup = 0x08,
    DomainLocalGroup = 0x04,
    GlobalGroup = 0x02,
    SecurityGroup = 0x80000000
}

+ Флаги, описывающие параметры пользователя:

[Flags]
public enum AdsUserFlags
{
    Script = 1,                          // 0x1
    AccountDisabled = 2,                 // 0x2
    HomeDirectoryRequired = 8,           // 0x8
    AccountLockedOut = 16,               // 0x10
    PasswordNotRequired = 32,            // 0x20
    PasswordCannotChange = 64,           // 0x40
    EncryptedTextPasswordAllowed = 128,  // 0x80
    TempDuplicateAccount = 256,          // 0x100
    NormalAccount = 512,                 // 0x200
    InterDomainTrustAccount = 2048,      // 0x800
    WorkstationTrustAccount = 4096,      // 0x1000
    ServerTrustAccount = 8192,           // 0x2000
    PasswordDoesNotExpire = 65536,       // 0x10000
    MnsLogonAccount = 131072,            // 0x20000
    SmartCardRequired = 262144,          // 0x40000
    TrustedForDelegation = 524288,       // 0x80000
    AccountNotDelegated = 1048576,       // 0x100000
    UseDesKeyOnly = 2097152,              // 0x200000
    DontRequirePreauth = 4194304,         // 0x400000
    PasswordExpired = 8388608,           // 0x800000
    TrustedToAuthenticateForDelegation = 16777216, // 0x1000000
    NoAuthDataRequired = 33554432        // 0x2000000
}