These new additions help us to create asynchronously running methods using the familiar synchronous development model. We don’t need to segment our code to extract the parts to be executed in a separate thread or to be a callback. We don’t have to think about the threads or tasks anymore – just add await and the rest is done automatically.

That’s cool – I really like these new features and I believe they can simplify our lives, but only when used properly. Current development stack (Win7/.NET Framework 4) does not enforce the asynchronous development model. The async functionality can be introduced into existing synchronous application once the developer has fully realized the advantages of the async APIs and has mastered their proper usage.

WinRT and .NET 4.5 are different – this stack forces us to use async model. Again, this is not a bad thing but it requires some discipline and some preliminary knowledge. Right now many developers are new to the field and are experiencing the following:

Developer: “I want to use this function to read some data”
Compiler: “Good, but you may want to use await to get the string”
Developer: “OK, await is added. Can I get the string?”
Compiler: “Sure, just add async in the method header”
Developer: “Added. F5!”
Developer: “Hey, it does not work! Where is my string?”

The code looks good, it can be compiled but does not work. Why? Here are two most common mistakes I have seen so far.

Example 1

WriteFileAsync function definition:

async public void WriteFileAsync(string filename, string contents)
{
    var localFolder = Windows.Storage.ApplicationData.Current.LocalFolder;
    var file = await localFolder.CreateFileAsync(filename, 
                           Windows.Storage.CreationCollisionOption.ReplaceExisting);
    var fs = await file.OpenAsync(Windows.Storage.FileAccessMode.ReadWrite);     
    //...
}

And this function is called as

WriteFileAsync("FileName", "Some Text");

In some cases this code will work properly. But only in some – if there is a code that depends on the file content or tries to access the same file and this code is called after WriteFileAsync(), the developer will be faced with an exception or unpredicted results.

The problem here is that the developer use awaits for the system calls but WriteFileAsync by itself is not awaitable and any code following after WriteFileAsync() call will be executed before all the expected saving operations are done. To fix the issue the method should be modified

async public Task WriteFileAsync(string filename, string contents)
{
    //...
}

And the function should be called as

await WriteFileAsync("FileName", "Some Text");

Example 2

To implement Windows 8 Sharing contract, an application should handle DataTransferManager.DataRequested event. Below you can see an example of such a handler:

async void DataRequestedHandler(DataTransferManager sender, DataRequestedEventArgs args)
{
    _fileStream = await _lastSelectedFile.OpenAsync(FileAccessMode.Read);
 
    args.Request.Data.Properties.Title = "Data Title";
    args.Request.Data.SetBitmap(_fileStream);
}

Not surprisingly, this sample does not work either. DataTransferManager does not expect that handler is asynchronous and when the await keyword returns control to the manager, the latter sees an empty data request object, assumes that the contract is not properly implemented and will not show the application on the Share panel. The fix is easy, we just need to move OpenAsync out of the method and to remove async keyword from the header, but this example demonstrates another kind of side effects – we should be very careful with the async functions when some data are expected to be returned to the external code.

These mistakes look trivial but chances are they will appear quite often due to deceptive simplicity of the new syntax. Hopefully, the next version of Visual Studio and/or ReSharper will be able to detect such situations and warn about them.

What is your opinion? Do you see a problem here?

1. MetroDemo demonstrates file system APIs and implementation of Share, File Picker and Search contracts.
2. TilesDemo demonstrates the basic manipulations with the application tiles.

• In addition to the contracts demonstrated during the demo, the attached code demonstrates an implementation of the Search contract.
• To see the demo in action your Pictures Library must contain at least one image tagged with some keywords. The keyword can be added in Windows Explorer by selecting the images and entering this data on the Details pane.
• What is ObservableVector.cs: ObservableCollection class is supported by Windows 8 Developer Preview but the change notification events are ignored by WinRT UI controls. ObservableVector class is a workaround to resolve the issue – it wraps an ObservableCollection object and allows us to send the notifications to the UI.

• Simple installation on any Windows-based PC. Installation and configuration should not require knowledge of the Web technologies.
• Ability to start, stop and configure the Web application from a custom desktop application.
• The Web application should be accessible for a local user and all the network users.
• In the same time it should be a regular ASP.NET application that can be deployed as a hosted solution.

It is clear that such solution will be composed from 3 main components: Web application, control application (in my case it is based on .NET/WPF), Web server. And the main question is “What should I use as a server?” To satisfy the project’s requirements, the server should have the following characteristics:

• Easily redistributable
• Configurable via API, configuration files or command line
• Should be controllable externally (Start/Stop via API, command line, etc.)
• Network support

CassiniDev

Already having an experience with CassiniDev server as a solution for the integration tests execution, I tried this one first. CassiniDev is an open-source project that includes a standalone Wev server with GUI and a library. The library, CassiniDev4-Lib.dll, contains CassiniDevServer class – an in-process Web server implementation.

_server = new CassiniDevServer();
_server.StartServer(@“\path\to\web\content”));

Basically, that’s it – with two lines of code you have a server that hosts your ASP.NET application. At first look this is what is required:

• there is no need to install anything – the server is a part of the control application
• CassiniDevServer can be easily configured and controlled

But there are some cavities and probably the main one is performance. CassiniDev handles all the HTTP requests sequentially, in one thread. It is acceptable for testing but is not practical in production.

Another issue that kicks CassiniDev out of completion is an auto-shutdown after 60-seconds of idleness – it simply stops to handle any incoming requests.

IIS Express

IIS Express is a lightweight version of IIS. It runs as a separate process like full version of IIS web server, but this process is executed under the user’s account. IIS Express is a standalone application and can be started/stopped using a command line, unlike service-based full IIS.

Theoretically IIS Express is xcopy-deployable, but EULA states that IIS Express can only be redistributed using an official installer package. That means if you want to use IIS Express, it should be added as a prerequisite to your installer and will be installed as separated product.

IIS Express uses the same configuration mechanism as full IIS. Probably the easiest way to host the site on IIE Express, is to create own applicationhost.config, deploy it on the target system and use it to start the server:

“C:\Program Files\IIS Express\iisexpress.exe” /config:D:\Fileversum\config\applicationhost.config

Even IIS Express is installed into the system it will not be started automatically on the Windows start. You have to do it by yourself by creating some kind of launcher or incorporating this functionality into the control application, to be able to start/stop the server on-demand.

By default IIS Express does not require elevated permissions, but in the same time it default configuration does not support network requests and port 80. You need the administrative privileges to unlock these features. The post by Scott Hanselman describes the required manipulations, but in short you need to do the following:

• Configure applicationhost.config to bind your site with the public IP address.
• Allow incoming connections and add a new Windows Firewall rule using netsh utility.

Note that netsh does not exist in Windows XP and httpcfg should be used instead. That means an additional complexity for the installation script.

UltiDev Web Server Pro

UltiDev Web Server Pro is a successor for UltiDev Cassini Web Server, a freeware redistributable Web server. The product is relatively new, but it is in active development and demonstrates a good stability, performance and a reach feature set.

Like IIS Express, UWS is a standalone out-of-process Web server. It runs as a service, includes GUI frontend but also provides an API and the command line tools. UltiDev Server cannot be privately deployed, you have to install it. Fortunately the server redistributable packages for InstallShield, Advanced Installer and VS bootstrapper are available.

If you prefer to register your site during the installation, UWS provides a command line utility that can be used for this propose. If you need more control under the site’s lifecycle, a .NET-based API exposed from UWS.Configuration.dll library might be an option. Below you can see a sample code demonstrating site registration:

var app = Metabase.GetWebAppEntry(ApplicationGUID, false);
app.VirtualDirectory = "/Fileversum";
app.PhysicalDirectory = @“\path\to\web\content”;
app.ApplicationName = "Fileversum";
app.AppType = ApplicationType.AspNetOrStaticHtml;
app.ListenAddresses.AddRange(new[] { new ListenAddress(80) });
 
Metabase.RegisterApplication(RuntimeVersion.AspNet_4, true, app);

And un-registration:

Metabase.UnregisterApplication(ApplicationGUID);

Both operations (registration and un-registration) require the administrative rights. So if this code is incorporated into the control application, it must be able to request the elevated partitions.

As soon as the site is registered, it will be available for the local and the network users. No additional actions are required to start the server or site after Windows reboot.

Additionally, to simplify the site deployment, UWS supports auto detection of the available ports.

Feel free to contact me if you want to discuss them.

Updated 2010/11/03: Presentation slides, demo project

This week, on Wednesday the 27^th and Thursday the 28^th of October, the TechDays Canada 2010 will take place in Toronto and I will be presenting a session on Wednesday the 27^th at 2:20pm.

The talk is called “Some Behind-the-Scenes Details about WPF MVVM Frameworks” and is about the Model-View-ViewModel pattern implementation details. Here’s the abstract:

Currently MVVM is a pattern of choice among WPF community but as any pattern, it allows different interpretations and implementations. As a result, we have multiple MVVM frameworks and a variety of ways to solve the common pattern-related problems. Some of the frameworks are lightweight, some are heavy but usually every of them will miss at least one nice feature you want to have. This session proposes to explore different approaches used by the frameworks to perform the common tasks. If you want to have a MVVM foundation fully satisfy your project needs, this session can be a good start point for you. During the session, we will talk about different ways to bind the presentation layers, to discover ViewModels and make them blendable.

Below you can find a list of the described patterns with the names of the framework where they are used:

1. ViewModelLocator

MVVM Light Toolkit (Laurent Bugnion)

2. Attached Behaviors and MVVM

nRoute (Rishi)

JulMar MVVM Helpers + Behaviors (Mark Smith)

3. Using attached properties for ViewModel instantiation

MEFedMVVM (Marlon Grech)

Cinch (Sacha Barber)

4. Conventional binding, handling View lifecycle events from ViewModel

Caliburn.Micro (Rob Eisenberg)

5. Handling dialogs as services

Onyx (William E. Kempf)

6. ViewModelBase optimizations

ViewModelSupport (Brian Genisio)

Additional Resources

• MVVM Frameworks Explorer – MVVM frameworks comparison (Silverlight app)
• List of basic instantiation approaches
• WPF Disciples – Group for all WPF lovers, to share knowledge on WPF
• Build Your Own MVVM Framework by Rob Eisenberg, MIX10 (video)

• Presentation slides
• Demo project

public class Engine
{
   public double GetSize()
   {
      return 2.5; // in liters
   }
}
 
public class Car
{
   private readonly Engine _engine;
 
   public Car()
   {
      _engine = new Engine();
   }
 
   public void GetDescription()
   {
      Console.WriteLine(“Engine size: {0}”, _engine.GetSize());
   }
}
 
class Program
{
   static void Main()
   {
      Car car = new Car();
      car.GetDescription();
   }
}

Каждый из нас писал подобный код хотя бы раз в жизни. А те, в чьи обязанности входит проверка кода начинающих программистов, могут видеть это достаточно часто. С синтаксической и логической точек зрения в нем нет ничего криминального. Код отлично отработает, выполнив все от него ожидаемое, и в нем абсолютно ничего не надо трогать, если это часть программы состоящей из пяти классов. Вопросы возникают, когда такой код появляется в реальном проекте, насчитывающем десятки классов, имеющем длинный жизненный цикл и большую вероятность изменения пользовательских требований, способа хранения данных или поддерживаемого оборудования.

Чем же он плох? Если кратко, то зависимостью конкретного класса Car от конкретного класса Engine. Представим, что конструктор класса Engine измениться – в этом случае придется менять и Car. Или, к примеру, появиться еще один двигатель. И что бы машина смогла его использовать, опять-таки, понадобиться изменить класс Car. Кроме того, подобная жестко запрограммированная зависимость снижает тестируемость классов – класс Car невозможно протестировать отдельно от Engine или заменить Engine на ложный объект, для симуляции непредвиденных обстоятельств.

Что же можно сделать для улучшения кода? Первое – ввести интерфейс IEngine, который будет реализовываться классом Engine.

public interface IEngine
{
   double GetSize();
}
 
public class Engine : IEngine
{
   public double GetSize()
   {
      return 2.5; // in liters
   }
}

Далее, изменить класс Car, что бы вместо класса Engine в нем использовался интерфейс IEngine. И второе, не менее важное изменение – класс Car не должен создавать двигатель сам, теперь конструктор получает ссылку на объект, реализующий интерфейс IEngine.

public class Car
{
   private readonly IEngine _engine;
 
   public Car(IEngine engine)
   {
      _engine = engine;
   }
 
   public void GetDescription()
   {
      Console.WriteLine(“Engine size: {0}L”, _engine.GetSize());
   }
}

И последнее, что необходимо сделать – это изменить функцию Main.

class Program
{
   static void Main()
   {
      IEngine engine = new Engine();
      Car car = new Car(engine);
 
      car.GetDescription();
   }
}

Получившееся в результате решение легче расширяемо, более тестируемо и является примером реализации паттерна Dependency Injection (внедрение зависимости) – зависимость машина-двигатель конфигурируется не внутри класса, а двигатель, созданный вне класса, внедряется в него.

Минус такого решения – потерялась простота создания нового экземпляра класса Car. Представьте, если в программе достаточно много подобных зависимостей, их все придется создавать вручную снова и снова. Поэтому, мы пойдем дальше и посмотрим, как можно облегчить жизнь используя Ninject, фреймворк для автоматического внедрения зависимостей.

Ninject

Основную идею использования DI фреймворков для создания объектов можно описать так: “Мне нужен объект класса A, создай его, и меня не интересует, что и как ты для этого будешь делать”. И вот как будет выглядеть создание машины с использованием Ninject:

class Program
{
   static void Main()
   {
      // Ninject Initialization
      IKernel ninjectKernel = new StandardKernel( new MyConfigModule() );
 
      // Using Car
      Car car = ninjectKernel.Get<Car>();
      car.GetDescription();
   }
}

Что такое ninjectKernel станет понятно чуть позже, а сейчас стоит обратить внимание на отсутствие любого упоминания IEngine или Engine. Благодаря предварительной конфигурации Ninject знает, что машине требуется двигатель и когда его просят создать новый экземпляр класса Car, он самостоятельно создает Engine и передает его в конструктор Car. Таким образом, все что требуется – это запросить класс. Все зависимости, необходимые для его создания или работы, DI фреймворк разрешит самостоятельно. Если, конечно, он был предварительно правильно сконфигурирован.

Ninject можно или загрузить с сайта Ninject.org в виде стабильной версии, или взять в виде актуальных исходных файлов из репозитория. Я рекомендую воспользоваться вторым способом, так как версия, находящаяся в репозитории, поддерживает несколько новых возможностей, в том числе код для интеграции с ASP.NET MVC.

Для начала работы с Ninject, в проект необходимо добавить ссылку на сборку Ninject.Core.dll, реализующую базовые возможности фреймворка. Второй шаг – конфигурирование. К сожалению, Dependency Injection – это не магия и что бы Ninject знал, каким образом разрешать зависимости, он должен быть проинструктирован. Для нашей программы необходимы только две инструкции:

Bind<IEngine>().To<Engine>();
Bind<Car>().ToSelf();

В то время как многие DI фреймворки полагаются на конфигурационные XML файлы, Ninject имеет простой, интуитивно понятный API для задания зависимостей, использующий привычный синтаксис языка и позволяющий задействовать все возможности IDE.

Первая инструкция связывает интерфейс IEngine с классом Engine таким образом, что всякий раз, когда Ninject обнаружит необходимость в объекте типа IEngine, то будет создан объект Engine. Вторая инструкция описывает желаемое поведение при запросе на создание экземпляра класса Car – необходимо создать этот экземпляр, все просто. На самом деле, вторая инструкция не обязательна – такое поведение реализуется фреймворком по умолчанию. При необходимости автосвязывание классов можно и отключить, и настраивать все самому.

Теперь возникает вопрос – а где выполнять конфигурирование? Конфигурирование выполняется в виртуальном методе Load класса, реализующего интерфейс IModule. Проще всего будет наследовать такой класс от класса StandardModule.

public class MyConfigModule : StandardModule
{
   public override void Load()
   {
      Bind<Car>().ToSelf();
      Bind<IEngine>().To<Engine>();
   }
}

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

IKernel kernel = new StandardKernel(cfg1, cfg2, …);

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

Контрактное программирование – это метод проектирования программ, предполагающий четкое специфицирование интерфейсов и описание обязанностей компонентов системы при взаимодействии друг с другом.

Обычно, контракт включает три основные группы элементов:

• предусловия – обязательства, которые должны быть выполнены вызывающей стороной перед вызовом метода
• постусловия – обязательства, гарантирующиеся вызываемым методом
• инварианты класса – обязательства, что свойства класса будут удовлетворять определенным требованиям. Например, инвариантом для класса PositiveNumber, может быть утверждение, что хранимое число всегда больше или равно 0.

Таким образом, этот метод обеспечивает уверенность вызываемого компонента, что он получит только надлежащие входные данные, а результат, возвращенный вызывающему компоненту, будет корректным.

На PDC2008 было анонсировано появление в .NET 4.0 набора функций реализующих поддержку контрактного программирования и входящих в новое пространство имен System.Diagnostics.Contracts. На практике это будет выглядеть так:

class Account
{
   public double Balance { get; set; }

   public void Deposit(double amount)
   {
      Contract.Requires(amount >=0);

      Balance += amount;
   }

   public void Withdraw(double amount)
   {
      Contract.Requires(amount > 0);
      Contract.Requires(amount <= Balance);

      Balance -= amount;
   }

   public Account Transfer()
   {
      Contract.Ensures(Balance == 0);
      Contract.Ensures(Contract.Result<Account>() != null);

      Account newAccount = new Account() {Balance = this.Balance};
      Balance = 0;
      return newAccount;
   }

   [ContractInvariantMethod]
   protected void ValidAccount()
   {
      Contract.Invariant(Balance >=0);
   }
}

Как можно увидеть, контракт реализуется при помощи функций, что сразу вызывает вопрос, почему? Гораздо красивее была бы объявление контракта отдельно от кода, например с помощью атрибутов. К сожалению, атрибуты, по утверждению разработчиков, не позволяют описать все сценарии использования контрактов. Была возможность передавать в атрибуты сложные выражения, но они не захотели дублировать функциональность синтаксического анализатора. Так же они не захотели добавлять эту функциональность напрямую в язык, так как при этом другие .NET-языки не смогли бы ею воспользоваться. Так что мы имеем набор из десятка функций и нескольких атрибутов, которые войдут в mscorlib.

Code Contracts library

.NET 4 пока что не вышел, но попробовать контрактное программирование можно уже сейчас, загрузив библиотеку Code Contracts для .NET 3.5 с сайта Dev Labs. Библиотека доступна в двух вариантах: VSTS Edition для владельцев Visual Studio Team System, в которой доступны все возможности и ее применение разрешено в коммерческих целях, и Standard Edition для всех версий Visual Studio, за исключением Express Edition. Эта версия лицензируется для академических целей и не включает проверки контрактов во время компиляции.

При инсталляции, в систему добавляется библиотека Microsoft.Contracts, примеры и документация. Также, в Visual Studio инсталлятор добавляет в свойства проекта дополнительную страницу Code Contracts, на которой можно управлять поведением библиотеки. Для того, что бы начать работу с контрактами, в проект необходимо добавить ссылку на библиотеку Microsoft.Contracts.dll, расположенную в папке %PROGRAMFILES%/Microsoft/Contracts/PublicAssemblies.

Код, приведенный выше для примера, демонстрирует использование трех основных частей контракта: предусловий Contract.Requires в функциях Deposit и Withdraw, декларирующих, что они работают только с положительными суммами денег; постусловий Contract.Ensures в функции Transfer, которые заявляют, что в качестве результата функция должна вернуть новый счет и обнулить текущий; инварианта класса ValidAccount, утверждающего, что счет находиться в правильном состоянии, если его баланс больше или равен нулю.

Итак, контракт объявлен. Но что это нам дает? Что произойдет, если контракт будет нарушен, например, в случае такого вызова account.Deposit(-1000.0)? Это зависит от используемых настроек. Если включена статическая проверка контрактов, то уже на этапе компиляции будет выдано предупреждение о нарушении контракта. Если же включена только проверка контрактов во время выполнения, то, в простейшем случае, в момент вызова функции будет сгенерировано исключение ContractException. Если проверка отключена полностью, то никакой реакции не последует, так как в скомпилированном коде будут отсутствовать любые проверки.

• На самом деле код не просто скомпилирован, но и пропущен через модуль ccrewrite.exe, который подвергает полученный в результате компиляции IL-код постобработке, в результате чего декларация контракта превращается в конкретные вызовы методов проверки.

Дополнительно, библиотека позволяет достаточно гибко менять параметры runtime-проверки контрактов. Во-первых, можно задать какие именно части контракта необходимо проверять, например, только предусловия. И, во-вторых, можно перехватить событие Contract.ContractFailed или задать свой класс, методы которого будут вызываться вместо генерации исключения. Таким образом, к примеру, можно автоматически протоколировать нарушения контракта перед завершением программы.

Далее коротко пройдемся по всем основным элементам контракта.

Предусловия

Декларируют условия, необходимые для работы метода, выражаются с помощью Contract.Requires() и обычно используются для проверки входящих параметров. Функция Requires()принимает в качестве параметра логическое выражение выражающее условие контракта. Так же существует перегруженная функция, принимающая в качестве второго параметра строку – сообщение, используемое при нарушении условия.

Contract.Requires(amount > 0, "Invalid amount");

Как уже упоминалось выше, в зависимости от настроек текущей конфигурации в скомпилированном коде проверок контракта может и не быть. Однако, если вы хотите, что бы проверка предусловия осуществлялась всегда, вне зависимости от настроек, то можно использовать функцию Contract.RequiresAlways(), которая будет работать даже при отключеннии проверок в настройках проекта.

Contract.RequiresAlways(x != 0);

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

if (условие) throw new...

то, добавив вызов Contract.EndContractBlock() после этих проверок, вы превратите их в предусловия. Аналогичное действие окажет и вызов Contract.Requires(). На выражения накладываются следующие ограничения – они не должны выполнять ничего кроме генерации исключения, оператор else не поддерживается.

Постусловия

Постусловия декларируют состояние, достигнутое после завершения работы метода. Простой пример постусловия:

Contract.Ensures(Balance == 0);

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

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

Так, для верификации возвращаемого функцией значения используется специальный метод Contract.Result<T>(), где T – это тип возвращаемого функцией значения.

Contract.Ensures( Contract.Result<int>() > 0 );

Метод Contract.OldValue(e) позволяет получить значение переменной e до начала работы метода. Существует несколько ограничений на применение OldValue, главное из которых – переменная должна существовать перед началом выполнения инструкций метода и ее значение должно быть вычисляемым. В качестве таких переменных, например, могут выступать свойства класса или входящие переменные метода.

Contract.Ensures(Contract.OldValue(i) < n);

Для проверки в постусловиях значений out-переменных используется метод Contract.ValueAtReturn(out T t)

public void TestOut (out int a)
{
   Contract.Ensures(Contract.ValueAtReturn(out a) == 8);
   a = 8;
}

Инварианты класса

Инварианты класса относятся ко всему экземпляру класса и декларируют условия, при которых объект находиться в “хорошем” состоянии.

[ContractInvariantMethod]
protected void ValidAccount()
{
   Contract.Invariant(Balance >= 0);
}

Объявления всех инвариантов помещаются в один метод класса, помеченный атрибутом ContractInvariantMethod. Этот метод не должен содержать никакого кода, кроме объявлений инвариантов и не может возвращать значения. Каждый инвариант задается вызовом метода Contract.Invariant(). Проверка инвариантов класса происходит в конце каждого public метода класса – если посмотреть IL-код программы, то можно увидеть, что в процессе постобработки в конец каждого такого метода добавляется вызов нашей функции, помеченной атрибутом ContractInvariantMethod.

Дополнительно, в любом месте программы можно использовать Contract.Assert() для проверки условия в этой точке.

Contract.Assert( _number > 0 );

В процессе выполнения программы, если выражение ложно, то произойдет вызов Debug.Assert, в противном случае не последует никаких действий.

Контракты для интерфейсов

Описанные выше методы декларации контракта отлично работают в случае с конкретным классом. Однако что нам делать, если возникнет необходимость задать контракт для интерфейса? Ведь компилятор C# не позволит добавить для интерфейса тело функции с вызовом методов Contract.Requires() или Contract.Ensures(). На помощь приходит вспомогательный класс и пара атрибутов – ContractClass и ContractClassFor.

[ContractClass(typeof(SavingAccount))]
interface IAccount
{
   int Balance { get; }
   void Deposit(int amount);
}

[ContractClassFor(typeof(IAccount))]
class SavingAccount : IAccount
{
   int IAccount.Balance
   {
      get
      {
         Contract.Ensures(Contract.Result<int>() >=0 );
         return default(int);
      }
   }
   void IAccount.Deposit(int amount)
   {
      Contract.Requires(amount > 0);
   }
}

Для интерфейса создается вспомогательный класс, реализующий его и декларирующий контракт. Для установления связи между классом и интерфейсом используются атрибуты. Точно таким же способом можно объявить контракт для абстрактного метода, создав вспомогательного наследника и реализовав метод.

Поскольку статья задумывалась как введение в библиотеку Code Contracts, то я не стал описывать некоторые нюансы ее использования и методы, используемые в специальных случаях – с ними вы можете познакомиться в достаточно подробном документе, идущем вместе с библиотекой. Так же, для начала, может быть интересным видео с одним из разработчиков библиотеки, доступное на сайте Dev Labs.