Внимание опасность

Недавно я столкнулся с очень не хороший ситуацией. Один из наших хостингов провел плановое обновление программного обеспечения на своих северах. В ходе обновление был так же установлен net.framework3.5 SP1. 

После установки, сайты созданные на asp.net mvc перестали работать. В ходе кодокопания была выявлена следующая неприятная ситация.

Сайт был реализован на базе Asp.Net MVC Preview 2, в котором Dll выглядили следующим обазом:

System.Web.Abstractions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35

System.Web.Routing, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35

После выхода Asp.Net MVC Preview3 Сборки получили новые версии и стали выглядеть так.

System.Web.Abstractions, Version=0.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35

System.Web.Routing, Version=0.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35

Это было сделано, чтобы не вводить разработчиков в шоковое состояние от номера версии.

Но вот вместе с SP1 идут те самые две библиотеки, так как Microsoft включил их в ряд своих проектов(Dynamic Data, Data Services). Где они хранятся в следующем виде:

System.Web.Abstractions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35

System.Web.Routing, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35

Ничего не напоминает ? Это теже самые номера, что и в Preview2. В результате при работе компилятор подхватывает именно их. И в ходе работы можно столкнуться например с такой проблемой:

Не удалось загрузить тип "System.Web.HttpContextWrapper2" из сборки "System.Web.Abstractions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35".

Вот к чему приводит не согласованная политика версий...

+1

"И ты Брут", сказал бы Цезарь глядя на гугл. Гугл продвигается в сторону дескотпных приложений, выпустив свой броузер. Все кто заходили сегодня на сайт www.google.com могли видеть предложение о скачке их нового броузера Beta версии.

Могу сказать только одно, запостить этот пост, из него, мне удалось ) да и в интернете он неплохо лазиет, быстрее чем сафари, удобнее чем firefox+safary. Вообщем я сменил броузе с фаерфокса на Google Chrome.

Без шума и пыли.

Вышел очередной preview 5 Asp.net Mvc. Для установки необходимо снести старые preview.

• Замечено перемещение Ajax Helper в свое собственное пространство имен.

Насколько я понял, для легкой смены js ajax framework-а.

• IViewEngine немного поменял свою роль и теперь отвечает только за поиск View. 0_O
• Появление Html.RenderPartial

Танцы с IViewEngine стали понятны. Появление RenderPartial и ... и видимо идет движение в сторону subcontroller-ов.

• Added array support for action method parameters.
• Added support for custom model binders(ModelBinder(…)+.).

Насколько я понял теперь с клента в Action можно передавать массивы, а также более сложные типы данных.

• Added a new AcceptVerbs attribute.
• Added a new ActionName attribute.

А вот эти два момента приближают нас к простой full REST реализации ;)

И еще, еще, еще...
Общее впечатление от прочитанного релиза. Framework претерпел некоторый рефакторинг.

Трудности перехода

Судя вот по этой статье, некоторые американские разработчики видели веб-разработку только через призму asp.net. И после выхода asp.net mvc с удивлением для себя заметили, что вокруг мира веб-разработки существует куча других проблем, кроме "как найти подходящий aspnet control для моего сайта/интранет системы". Для человека, всегда работавшего с win-app, трудно понять, что его asp.net приложение не работает, как он хочет, во всех броузерах. Трудно понят, что приложение не хранит состояние между сессиями. Трудно понять почему ему приходится делать работу два раза, clien-side и server-side.

Насчет споров вокруг asp.net mvc. По мне так все эти споры связаны в основном из-за того, что люди приходящие в веб разработку делают это с разных сторон и со своим сложившемся мировозрением на построение приложений.

Кто-то пришел из мира win-application и увидел родной для себя подход в classic asp.net. Кто-то пришел из мира web-application(perl,php,ruby и так далее и тому подобное).

Я так думаю MS не стало бы возиться с asp.net mvc если бы не видело проблем которые пораждает classic asp.net.

PS. Интересно, сколько человек откликнется на этот пост )

Все когда-нибудь заканчивается

Отпуск тоже когда-то кончается и наступают рабочие будни.

• Отдыхать в городе - это убийство своего отпуска.
• Отдыхать в другом городе - это покушение на убийство.
• Поход по магазинам во время отпуск - это ограбление своего отпуска.
• Отсыпаться во время отпуска - это убийство своего отпуск.
• Поездка на курорт - это гастроли с совершение тяжких телесных повреждений(отравление, ожирение и обгорание)

ТОЛЬКО АКТИВНЫЙ ВИД ОТДЫХА, в любом его проявлении и виде!
Остальное тут

Использование Http Status Code для обработки ошибок

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

Для любого ответа web-сервер генерирует Status Code. Статусы есть наверное на все случаи жизни сервера и request-а.
Классические:
200 OK - все верно обработано
301 Moved permanently - так называемый редирект
403 Forbidden - нет доступа
404 Not Found - нет такого ресурса
Более экстравагантные:
405 Method Not Allowed
411 Length Required
505 HTTP Version Not Supported

Есть еще один статус, который возникает если во время обработки запроса произошла ошибка в коде "500 Internal Server Error".
Как правило пользователь в браузере видет какую-то жуть несусветную и все исключения или ошибку стараются обработать на сервере и выдать в каком-нибудь удобоваримом виде. После такой обработки тот самый "500" статус теряется и теперь сервер возвращает "200 OK".
Далее на клиенте просто выводится текст ошибки, ну или на что фантазии хватит у разработчика.

Большинство браузеров или js-framework умеют работать с 500 статусом. Например при ajax запросе js-frameworks вываливаются в методы(OnError, onFailure). Броузеры имеют свою страничку для отображения ошибок.
Но, после обработки "500" статус пропадает и "клиент" не узнает об ошибке. Приходиться вводит и обрабатывать дополнительную ситуацию на "клиенте", придумывать форматы для информирования об ошибке и так далее.
Зачем городить огород, если клиент и так настроен на обработку "500" кода. Для того, чтобы клиент все правильно понял достаточно после обработки в HEADER опять поместить "500" ошибку.
Для этого можно записать в респонсе(Asp.Net Mvc):

Response.StatusCode = "500";

Теперь клиент правильно поймет, данные относятся к ошибке. А на сервере надо будет правильно эти данные сформировать. Информированием клиента об ошибке займется протокол HTTP.