2013-11-07 3 views
1

У меня один на один. Я использую Code Contracts в сценарии, где методы, к которым применяются контракты, являются реализациями интерфейса. Итак, я использую абстрактный подход ContractClassFor для определения требований контракта. Это отлично подходит для одного из классов реализации (он, оказывается, находится в том же проекте, что и интерфейс), но контракты никогда не применяются ко второй реализации (которая находится в отдельном проекте). Оба проекта имеют одинаковые параметры Контракта Контракта (требуется стандартный контракт, полная проверка контракта во время выполнения). Ниже приведен сценарий в коде:Код Контракты, не применяемые при использовании ContractClassFor

namespace First.Interfaces { 
    [ContractClass(typeof(ContractForIMyClass))] 
    public interface IMyClass { 
     void MyMethod(int id); 
    } 

    [ContractClassFor(typeof(IMyClass))] 
    public abstract class ContractForIMyClass : IMyClass 
    { 
     void MyMethod(int id) { 
      Contract.Requires<ArgumentException>(id != 0); 
     } 
    } 
} 

namespace First { 
    public class MyClass : IMyClass { 
     public void MyMethod(int id) { 
      //contract is applied here 
     } 
    } 
} 

namespace Second { 
    public class MyTestClass : IMyClass { 
     public void MyMethod(int id) { 
      //contract is not applied 
     } 
    } 
} 

Любые мысли, на которые следует обратить особое внимание.

ответ

4

Вам нужно сделать две вещи для этой работы:

  1. Построить ссылочный договор сборки для сборки, который содержит интерфейс.
  2. Используйте этот сборник ссылок при создании проекта, содержащего второй класс.

Оба параметра можно контролировать из раздела «Кодовые контракты» на страницах свойств соответствующих проектов в Visual Studio. (Если вы используете стандартные ссылки на проекты в рамках одного решения, вам, вероятно, не придется ничего делать за # 2, если вы исправили # 1.)

+0

О, Microsoft. Что * не может * вы раздуваться и уродливо. Работает, спасибо! – sydneyos

Смежные вопросы