#aspnetwebapi

[eagafonov]

Мой доклад про ASP.NET на конференции DevCon 2013

29 мая в 14:30 я буду выступать на конференции #msdevcon c докладом про ASP.NET и Windows Azure. Доклад крайне эксклюзивный, так как ни в одном другом докладе на этой конференции, ни в названиях тем, слово ASP.NET больше не встречается. Я планирую рассказать о том, почему с ASP.NET происходит страное :), ожидает ли эту технологию судьба известного персонажа,

cравнивать ASP.NET с другими технологиями,

показывать интересные вещи внутри платформы, оценивать производительность, продемонстрировать интеграцию с windows azure, и многое другое. И все - за час времени! Хочу задать вопрос - нужно ли рассказывать про web forms? Насколько много людей, которым это еще интересно? Нововведения в web forms есть, но стоит ли их показывать, или же все-таки сосредоточиться на чем-то другом? И конечно, если есть конкретные пожелания к содержанию доклада или вопросы, с радостью бы их выслушал.

[eagafonov]

IIS 8, HTTP OPTIONS, CORS и ASP.NET Web API

Сегодня столкнулся с интересной проблемой. На одном из web api под IIS 8 не работала поддержка CORS из nuget-пакета Thinktecture.IdentityModel. Здесь можно посмотреть пример использования этой библиотеки, и здесь - как нужно сконфигурировать приложение для корректной работы. Просмотр запросов с помощью fiddler дал понять, что в ответ на http запрос OPTIONS сервер отвечает простым ответом ОК без указания нужных заголовков, в частности - Access-Control-Allow-Origin. Опытным путем обнаружилось, что если на сервере включить опцию RAMMFAR ( runAllManagedModulesForAllRequests="true"), то delegating handler для поддержки CORS начинает работать. Однако включать эту опцию не очень хотелось, пусть даже она влияет не на все managed модули, поэтому я продолжил исследования дальше. Выяснилось что в моем случае в IIS установлен еще один хэндлер - OPTIONSVerbHandler. Как только я его убрал в web.config, приложение стало работать нормально при выключенной опции RAMMFAR. Вот, что в итоге получилось в web.config:

[eagafonov]

IIS 8, HTTP OPTIONS, CORS and ASP.NET Web API

Today I met the challenging problem with one of my web apis running under IIS 8. CORS support which was implemented with nuget library Thinktecture.IdentityModel didn't work properly. Here you can find information how to use this library, and here is the link to configuration issues with IIS. After spending some time with a fiddler tool I found out that the client sends the proper HTTP OPTIONS request, but the response from server lacks Access-Control-Allow-Origin and other useful http headers. After some experiments it turned out that if I enable RAMMFAR option ( runAllManagedModulesForAllRequests="true") in web api web.config, the CORS delegating handler starts to work. However I don't like turning on this option, even if it doesn't really affect all managed modules in IIS, so I kept experimenting. I found out that there is another handler defined in IIS, called OPTIONSVerbHandler. As soon as I removed it via application web.config file, CORS support started to work properly without need to enable RAMMFAR option. This is system.webServer section in web.config:

[eagafonov]

Как писать тесты для ASP.NET Web API RC

После миграции на APS.NET Web API RC в одном из моих приложений у меня сломались все тесты. Довольно быстро удалось выяснить, что причина - NullReferenceException, который возникает по причине изменения способа конструирования HttpResponseMessage в ASP.NET Web API RC. Вместо того, чтобы создавать новый экземпляр HttpResponseMessage, теперь надо вызывать метод Request.CreateResponse(), а в тестовом окружении, естественно, свойство Request у контроллера было null.

Чтобы это исправить, я создал экземпляр HttpRequestMessage, и назначил его свойству Request тестируемого контроллера. Но этого оказалось недостаточно, и вот дальше найти, что происходит и как все починить, было не совсем просто :)

Следующая проблема заключалась в том, что экземпляр HttpRequestMessage должен содержать в себе экземпляр HttpConfiguration, и чтобы его прикрепить, нужно было его назначить по хитрому ключу в словарь свойств HttpRequestMessage.Properties. Ниже пример кода, который у меня работает:

[eagafonov]

Writing Unit Tests For ASP.NET Web API RC

After I moved one of my solutions to ASP.NET Web API RC I found almost every test broken. A quick investigation shown, that I get null reference exceptions, because of new HttpResponseMessage creation paradigm in ASP.NET Web API RC. Instead of creating new HttpResponseMessage instance, I now have to call Request.CreateResponse() method, and obviously I had null Request in my test environment.

So, I instantiated a new HttpRequestMessage instance and added it to the Request property of the controller being tested. But this was not enough to fix things, and the next problem wasn't that obvious and took time for me to find out the solution.

The next problem was that newly created request message lacked an instajce of HttpConfiguration attached to it. And to attach this configuration to the request message, one have to set this instance into HttpRequestMessage.Properties dictionary by the special key. So, the following is the final code which fixed my tests: