Общие знания .NET внутри [дубликат]
Если вы получаете это сообщение во время сохранения или компиляции сборки, просто закройте все файлы, а затем откройте любой файл для компиляции и сохранения.
Для меня причина в том, что я переименовал файл, и старый файл все еще был открыт.
2 ответа
Кодовые контракты были введены в .NET 4.0, и они предоставляют язык-агностический метод для выражения предположений о кодировании в программах.
Они в основном позволяют вам проверять предварительные условия, пост-условия и другие функции и могут значительно улучшить процесс тестирования и возможное качество кода, который записывается.
Microsoft:
- Проверка времени выполнения. Наш бинарный перезаписывающий модуль модифицирует программу путем ввода контрактов, которые проверяются как часть программы> выполнение. Переписанные программы улучшают тестируемость: каждый контракт действует как оракул, давая тестовый прогон индикацию прохода / сбоя. Автоматические инструменты тестирования, такие как Pex, используют контракты для создания более значимых модульных тестов путем фильтрации бессмысленных тестовых аргументов, которые не удовлетворяют предварительным условиям.
- Статическая проверка. Наш статический контролер может решить, есть ли какие-либо нарушения контракта, даже не запуская программу! Он проверяет неявные контракты, такие как нулевые разыменования и границы массива, а также явные контракты.
- Генерация документации. Наш генератор документации дополняет существующие файлы документов XML с информацией о контрактах. Также есть новые таблицы стилей, которые можно использовать с Sandcastle, чтобы сгенерированные страницы документации имели секции контрактов.
Подробнее:
-
1– Paul Gleeson 9 December 2011 в 20:55
Кодовые контракты являются относительно новым способом выполнения проверок ввода и вывода функций. Там, где они отличаются от стандартной проверки типа Assert, выполняется то, что сгенерированный IL, который проверяет ввод, проверяет его непосредственно перед вызываемой функцией и код, который проверяет вывод, после того, как ваша функция действительно вышла.
Почему это полезно?
Ну, это мешает вам изменять переменные после того, как вы думаете, что ваша функция может вернуться, тем самым потенциально представляя ошибки.
Вот пример.
public void doSomething(SomeObject foo)
{
Contract.Requires<ArgumentNullException>(foo != null);
}
Теперь в кодовых контрактах требуется, чтобы перед этой проверкой не было кода. В сгенерированном ИЛ значение foo проверяется PRIOR на вызов. Это надежный способ гарантировать, что ваш вход будет таким, как ожидалось.
Другой - это Contract.Ensures. Это в основном похоже на Requires, но работает с вашим возвращаемым значением.
public int doSomethingElse()
{
Contract.Ensures(Contract.Result<int>() != 0);
int ret = 1;
return ret;
}
Это было бы особенно полезно, если бы у вас было несколько путей выхода из вашей функции ...
public int someBadFunction()
{
Contract.Ensures(Contract.Result<int>() != 0);
if(....)
{
if(....) return 2;
if(....) return 8;
}
return 3;
}