В моем .NET-решении у меня есть два проекта: один основной проект и проект для запуска тестов против основного проекта. В моем проекте у меня есть несколько методов, которые я хотел бы сохранить «частными», но также хотел бы запустить тесты. Есть ли способ доступа, который может ограничивать эти функции только внутри моего решения?Есть ли модификатор доступа, который ограничивает решение?
Вы ищете атрибут InternalsVisibleTo.
Эти атрибуты позволяют указывать другие сборки, которые должны иметь доступ к типам и методам, которые являются внутренними для вашей сборки. Таким образом, в основной проект AssemblyInfo.cs файла (или любого другого исходного файла), вы можете указать, что тестовый проект является «другом сборки» и должны иметь доступ к внутренностей вашего основного проекта:
[assembly:InternalsVisibleTo("MainProject.Tests")]
На стороне примечания, как отметил Алексей, если ваш основной проект подписан с сильным ключом, любая сборка «друга» также должна быть подписана. Это объясняется here
Хотя, как указано в другом комментарии. Лучшая практика - протестировать вашу сборку, используя свой общедоступный API.
Сторона примечания: подход «InternalsVisibleTo» не работает для многих людей из-за сильных требований к подписанию. –
Вы можете использовать атрибут InternalsVisibleTo, чтобы сделать виды и методы internal видными для выбранных сборок.
Однако вы должны попробовать создать свой API так, чтобы его можно было протестировать, используя только открытый интерфейс.
Вам следует серьезно подумать об архитектуре вашего решения. Это запах, который часто показывает, что ваш класс делает слишком много вещей сразу.
Простое исправление, чтобы извлечь эту ответственность (эти частные методы) в другой класс, где они затем становятся public и являются проверяемыми из коробки ...
Нет, нет никакого способа, чтобы ограничить доступ к " просто решение ».
Причина в решении - это просто группа проектов. Один проект может быть в любом количестве решений. Поэтому, даже если вы «ограничиваете» доступ к проектам, включенным в одно решение, вы/кто-то еще можете создать другое решение, которое каким-то образом должно будет волшебным образом получить доступ к методам.
Дополнительно встроенная сборка не содержит никакой информации о том, какое решение она была частью - так что во время выполнения нет информации для проверки доступа.
Для вас конкретная проблемы - InternalsVisibleTo (как показаны на other answers) даст доступ к внутренним методам проектов вы предоставите (требуется сильно подписанные сборки) или рефакторинг кода, чтобы избежать необходимости тестирования частных методов.
Можно утверждать, что вы должны тестировать только ваш общедоступный API, но вы можете использовать внутренние и внутренние интерфейсыVisibleTo, чтобы позволить тестовому проекту увидеть их. – juharr