Как хорошая идея - это для использования контрактов кода в Профессионале Visual Studio 2010 года (т.е. никакая статическая проверка) для библиотек классов?

Я создаю библиотеки классов, некоторые, которые используются другими во всем мире, и теперь, когда я начинаю использовать Visual Studio 2010, я задаюсь вопросом, как хорошая идея это для меня для переключения на использование контрактов кода вместо регулярных операторов "if" старого стиля.

т.е. вместо этого:

if (fileName == null)
    throw new ArgumentNullException("fileName");

используйте это:

Contract.Requires(fileName != null);

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

Таким образом, у меня есть несколько вопросов:

• Находится статическое средство проверки на по умолчанию, если у Вас есть доступ к нему? Или есть ли установка, которую я должен включить в библиотеке классов (и так как у меня нет статического средства проверки, я не буду),
• Действительно ли мои страхи являются неоправданными? Является вышеупомянутый сценарий настоящей проблемой?

Любой совет приветствовался бы.

Править: Позвольте мне разъяснить то, что я имею в виду.

Скажем, у меня есть следующий метод в классе:

public void LogToFile(string fileName, string message)
{
    Contracts.Requires(fileName != null);
    // log to the file here
}

и затем у меня есть этот код:

public void Log(string message)
{
    var targetProvider = IoC.Resolve<IFileLogTargetProvider>();
    var fileName = targetProvider.GetTargetFileName();
    LogToFile(fileName, message);
}

Теперь, здесь, МОК умирает, разрешает некоторый "случайный" класс, который предоставляет мне имя файла. Скажем, это для этой библиотеки, нет никакого возможного способа, которым я могу возвратить класс, который не даст мне непустое имя файла, однако, из-за природы вызова МОК, статический анализ не может проверить это и таким образом мог бы предположить, что возможное значение могло быть нулевым.

Следовательно, статический анализ мог бы прийти к заключению, что существует риск LogToFile метод, называемый с a null аргументу, и таким образом не удается создать.

Я понимаю, что могу добавить предположения коду, говоря, что компилятор должен взять его в качестве, учитывая, что fileName Я возвращаюсь из того метода, никогда не будет пустым, но если бы у меня нет статического анализатора (Профессионал VS2010), вышеупомянутый код скомпилировал бы для меня, и таким образом я мог бы оставить это как ошибку сна для кого-то с Окончательным для нахождения. Другими словами, не было бы никакого времени компиляции, предупредив, что могла бы быть проблема здесь, таким образом, я мог бы выпустить библиотеку как есть.

Таким образом, действительно ли это - реальный сценарий и проблема?