Могу ли я вызвать зависимость между пространствами имен в C #

Question

Можно ли ограничить классы из определенного пространства имен ссылками на классы в другом конкретном пространстве имен? Оба пространства имен существуют в одной сборке .NET.

Пример:

namespace LegacyCode
{
    class LegacyClass { ... }
}

namespace NewCode
{
    class NewClass {...}
}

Я не хочу, чтобы классы из 'NewCode' могли ссылаться на классы в 'LegacyCode'.

Параметры:

1. Наличие разных сборок (затрудняет развертывание, сборка занимает больше времени)
2. Использование такого инструмента, как NDetect (стоит денег!)

У кого-нибудь есть другие идеи?

Answer 1

Попробуйте пометить классы Устаревшим атрибутом . Это приведет к тому, что любой код, который сам не помечен как устаревший, будет генерировать предупреждение во время компиляции.

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

Edit:

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

Редактировать # 2:

Спасибо Дэн Тао за указание на перегруженный конструктор атрибута "Устаревший". Это означает, что вы можете указать, следует ли рассматривать использование чего-либо как ошибку или нет, без необходимости включать предупреждения как ошибки. Существует также полезная опция для указания сообщения, инструктирующего пользователя об обходном пути. Это сообщение отображается во время компиляции в сообщении об ошибке / предупреждении.

Answer 2

Документирование дизайна, общение с людьми, просмотр кода.Не пытайтесь бросать технологии на проблемы людей.(Однако обзорная часть может стать более эффективной с помощью таких инструментов, как NDetect.)

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

Answer 3

MS использует атрибут System.ObsoleteAttribute для пометки устаревшего / устаревшего кода. Этот атрибут обеспечивает ctor, который создает ошибку компилятора. Хотя я бы использовал это, если бы не слишком много унаследованных классов.

Answer 4

Я думаю, что отдельные сборки - единственно возможное решение.

Answer 5

Как уже говорили другие, используйте устаревший атрибут (даже если вам нужно его переименовать).

Но сделайте еще один шаг.УДАЛИТЬ ЛЮБОЙ Устаревший метод, который больше НЕ используется как можно скорее.Это будет препятствовать тому, чтобы кто-то использовал это позже.Вы должны начать видеть предупреждения компилятора из-за устаревших атрибутов, которые пропадают со временем.

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