F>Я извиняюсь, то ли чего-то не понял... Но разве ASP.NET/XSP-хосты так не работают?
Нет конечно, не так. Домен просто перезапускается.

F>ЗЫ: Лучше скажите как обновить windows-service с минимальным временем простоя, без собственных велосипедов. Собственный блэкджек будет, но позже, а пока...
Для этого надо иметь Load Balancer и 2 backend server-а.
Алгоритм простой:
1. Отключаем один из серверов от LB, таким образом запросы на него не приходят
2. Обновляем отключенный сервер
3. В LB отключаем второй сервер и включаем первый
4. Обновляем второй сервер
5. Включаем в LB второй сервер

Мы данный подход используем на практике когда надо обновить сервер вне maintenance window.

Здравствуйте, ionoy, Вы писали:

А>>StackOverflow jRebel — 238 search results
А>>StackOverflow "edit and continue" — 270 search results
I>Правильно, потому что "edit and continue" больше создаёт проблем, чем решает.
Это такие глобальные выводы сделаны что количество тем на 15% больше?
А почему тэги, тогда обойдены, там же противоположная ситуация?

I>Да, но только я слабо представляю, какие переменные нужно менять в экшенах.
I>Зато представляю, что часто приходится добавлять параметры, поля во viewmodel, изменять запрос к базе.
Например запрос к базе в переменной, взяли и поменяли.

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

I>И что нужно реализовывать в Javascripte или Ruby? Изменение кода во время дебага?
Не обязательно нужно, а сравнительно нетрудно сделать по сравнению с Java, в этом была мысль.

I>Я встречал только людей, которые отключали её из-за того, что она часто вылезает когда не надо.
Тем не менее она заметно поднимает производительность труда программиста.
Неоднократно встречал просьбы в интернете сделать поддержку для GDB, GCC, Java и т.д.

I>В том то и дело, что она напоминает о себе, когда у тебя неожиданно срабатывает брейкпойнт. Очень бесячая штука.

I>Ну так докажи, что они самые распространённые.
Уже доказал пару раз. Повторяю — это первое что пришло вам в голову когда вы писали зачем нужен аналог jRebel на Nemerle.

I>Я думаю ты и сам знаешь, что таскать объекты из одного домена в другой удовольствие не из приятных.
Вот с этим категорически не согласен. Веб-сервисы и сама WCF давно это дыру закрыли, и все сделали очень прозрачным. Есть в Visual Studio соответствующие визарды, да и многое вообще декларативно.
То есть нетрудно сравнительно быстро разделить приложение физически на две части, если оно и так уже логически разделено. А отдельные части потом можно запускать хоть в разных доменах, хоть на разных машинах, меняются только конфиги.

I>Точно уверен? Может они и библиотеки только подписанные используют?
Думаю так и есть, это одна из дополнительных защит, зачем её избегать, особенно когда за работу платят приличные деньги. Не удивлюсь если у них просто политика безопасности на серверах, единая на всех, запускаются только подписанные приложения, да еще и из белого списка. То есть подписывать не подписывать, решают не разработчики, а админы серверов.

I>Критическое замечание было только одно: есть Edit and Continue. Я на это ответил, что он даже близко не сопоставим по возможностям.
С этим согласен, даже близко не сопоставим, а гораздо круче.
Впрочем мы начинаем ходить по кругу.

I>Так ругай по делу, конструктивно.
Я и выступаю максимально конструктивно, даже приводил статистику.

Короче, еще разок приведу свое мнение:
jRebel на платформе .NET не нужен.
Для изменения переменных во время отладки используйте Edit and Continue.
Для ускорения развертывания приложения, разбивайте его на отдельные части, это поможет и в дальнейшем для масштабирования приложения, эти отдельные части можно будет развертывать на отдельных машинах. А jRebel условно поможет только в разработке.

Здравствуйте, Ziaw, Вы писали:

VD>>В нем есть подстветка немерла

Z>На битбакете тоже есть ) Имхо, там те же пигменты, что и на гитхабе.

Ты бы на ссылку, что в тематическом сообщении, нажал бы для начала. Я как-то там не заметил подсветки.

Здравствуйте, WolfHound, Вы писали:

WH>Edit and continue был еще в VC++6.
WH>В VC++7 я его использовал на практике.
Я имел ввиду Managed C++.

I>>>Потому что в том виде, в котором эта фича реализована она никому не нужна.
А>>Нужна очень многим, даже в текущем виде.
WH>В текущем виде она действительно малополезна.

I> Не нужна
A> Нужна
W> Малополезна


Для изменения значения переменной во время отладки вполне себе полезна.
Конечно, было бы хорошо иметь меньше ограничений, но и в текущем виде многими считается одним из существенных преимуществ Visual Studio над другими IDE.

Здравствуйте, Аноним, Вы писали:

А>Короче, еще разок приведу свое мнение:
А>jRebel на платформе .NET не нужен.
А>Для изменения переменных во время отладки используйте Edit and Continue.
А>Для ускорения развертывания приложения, разбивайте его на отдельные части, это поможет и в дальнейшем для масштабирования приложения, эти отдельные части можно будет развертывать на отдельных машинах. А jRebel условно поможет только в разработке.

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

Здравствуйте, VladD2, Вы писали:

VD>Ты бы на ссылку, что в тематическом сообщении, нажал бы для начала. Я как-то там не заметил подсветки.

https://bitbucket.org/ionoy/easymvc_nemerle/src/4743e0727461/EasyMVC.Macros/LatePrivate.n

Есть подсветка.

Здравствуйте, Аноним, Вы писали:

А>Для изменения значения переменной во время отладки вполне себе полезна.

Изменить значение переменной в отладчике можно и без всяких эдтиов энд континью (с) маркетологи. Оно на то и значение.

Edit and continue полезен когда нужно что-то поправить по мелочи и пойти дальше. Фича приятная не спорю. Но так же глупо спорить и стем, что полезна она очень редко. А с появлением linq-а она становится и вовсе бесполезной, так как замыкания теперь просто везде.

В общем, было бы конечно просто супер, если статически типизированные компилируемые программы можно было бы менять как срипты. Но пока что это не так. А стало быть аналог jRebel не помешает.

Интерактивность разработки — это довольно важный аспект. На мой взгляд главный недостаток немерла — низкая скорость компиляции.

А>Конечно, было бы хорошо иметь меньше ограничений, но и в текущем виде многими считается одним из существенных преимуществ Visual Studio над другими IDE.

Если многими, то тебе не составит труда дать ссылок на подобные мнения?

Здравствуйте, _NN_, Вы писали:

_NN>https://bitbucket.org/ionoy/easymvc_nemerle/src/4743e0727461/EasyMVC.Macros/LatePrivate.n

_NN>Есть подсветка.

Хм. Чудеса да и только. Когда я отвечал ее не было. Зуб даю.

Здравствуйте, ionoy, Вы писали:

I>В мире Java есть такой удобный инструмент, который называется jRebel...

А можно в двух словах описать как этим делом пользоваться?

Здравствуйте, VladD2, Вы писали:
VD>А можно в двух словах описать как этим делом пользоваться?
1. Создаём MVC 2/3/4 проект
2. Качаем из раздела Downloads последние бинарники
3. Добавляем в проект ссылку на EasyMVC.dll
4. В конец метода Application_Start (global.asax.cs) добавляем строку:

EasyMVC.Easy.Init();

5. Запускаем

Теперь можно зайти например в HomeController, поменять значение Message строки и рефрешнуть браузер.
Строка должна измениться при том, что домен не перегружался.
Потом ради интереса можно добавить статическую переменную в класс контроллера и использовать её в той же строке. Статические переменные копируются после ребилда, так что такой код:

static int counter = 0;
public ActionResult Index() 
{
   ViewBag.Message = (counter++).ToString();
   return View();
}

Будет работать так, как и ожидалось.

Менять в коде приложения можно абсолютно всё. Главное, чтобы вызываемый контроллер был на месте.

Здравствуйте, VladD2, Вы писали:

VD>Изменить значение переменной в отладчике можно и без всяких эдтиов энд континью (с) маркетологи. Оно на то и значение.
Под значением имелось ввиду естественно сравнительно сложное выражение, а не литерал или простое присваивание другой переменной.

VD>А с появлением linq-а она становится и вовсе бесполезной, так как замыкания теперь просто везде.
Пока микрософт заявляет, что потребуется серьезная переработка для API дебаггера.
Но будем ждать.

VD>А стало быть аналог jRebel не помешает.
Это подход не с той стороны. И вообще в каком-то смысле самопротиворечив.
Если у вас небольшой проект, то деплоймент быстрый и проблемы нет.
Если же проект большой, то лучше его не делать в виде монолита, а разбить на части, сведя к первому случаю.

VD>На мой взгляд главный недостаток немерла — низкая скорость компиляции.
А это не про скорость компиляции, а про скорость развертывания — деплоймент.
Компиляция никуда не девается.

А>>Конечно, было бы хорошо иметь меньше ограничений, но и в текущем виде многими считается одним из существенных преимуществ Visual Studio над другими IDE.

VD>Если многими, то тебе не составит труда дать ссылок на подобные мнения?
http://stackoverflow.com/questions/4303599/edit-and-continue-on-gdb
Вот цитата по ссылке

my experience says it's the first thing MSVC users mention when asked "why not switch to Eclipse and gcc/gdb"

Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, VladD2, Вы писали:

VD>>Ты бы на ссылку, что в тематическом сообщении, нажал бы для начала. Я как-то там не заметил подсветки.
_NN>https://bitbucket.org/ionoy/easymvc_nemerle/src/4743e0727461/EasyMVC.Macros/LatePrivate.n

_NN>Есть подсветка.

"Ты, демон, как ты это сделал? Ты как под ламинат залез?" (с)

Здравствуйте, Tom, Вы писали:

Tom>Для этого надо иметь Load Balancer и 2 backend server-а.
Спасибо. К такому решению я и сам пришел, но пока что работа вне кластера.

Здравствуйте, ionoy, Вы писали:

I>В мире Java есть такой удобный инструмент, который называется jRebel. В двух словах, он позволяет изменять код веб приложения без перезагрузки домена. То есть исправил ты значение переменной в контроллере, нажал ctrl+s и можешь уже обновлять страницу в браузере. Так же как если бы ты кодил на PHP или другом интепретируемом языке.

То что вы реализовали есть в Orchard CMS, но без перестроения контейнера. Решение основано на Autofac IoC, конкретно с помощью вложенных Scope.
Объекты в контейнере по Scope делятся на три типа: корневой, модульный, все остальные (создаваемые на каждый запрос, на каждый inject).
Корневые объекты загружаются в контейнер при старте приложения и не выгружаются до конца работы. Модульные объекты загружаются при старте приложения, при включении/отключении плагина и при перекомпиляции модуля. Контроллеры относятся к модульным объектам. Когда происходит перекомпиляция Scope уровня Module уничтожается и создается заново, то же самое происходит при загрузке/выгрузке плагинов. Такое подход избавляет от заказа солнца вручную

Здравствуйте, Аноним, Вы писали:

VD>>Изменить значение переменной в отладчике можно и без всяких эдтиов энд континью (с) маркетологи. Оно на то и значение.
А>Под значением имелось ввиду естественно сравнительно сложное выражение, а не литерал или простое присваивание другой переменной.

Да без разница какой сложности инициализирующее значение. Это все равно не связано с Edit and continue.

Edit and continue — это когда код меняется во время отладки. Он при этом перекомпилируется.

VD>>А с появлением linq-а она становится и вовсе бесполезной, так как замыкания теперь просто везде.
А>Пока микрософт заявляет, что потребуется серьезная переработка для API дебаггера.
А>Но будем ждать.

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

Полностью проблему им не решить без внесения изменений в дотнет. Основная проблема там — это подмена типов. Типы в дотнете — это статические конструкции на которые много чего завязано.

Так что гибкости динамически типизированных языков вряд ли в ближашие лет 10 удастся добиться.

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

VD>>А стало быть аналог jRebel не помешает.
А>Это подход не с той стороны.

Это реальное решение реальной задачи. Лишь бы он работал.

А остальное — бессмысленное сотрясение воздуха.

А>И вообще в каком-то смысле самопротиворечив.
А>Если у вас небольшой проект, то деплоймент быстрый и проблемы нет.

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

А>Если же проект большой, то лучше его не делать в виде монолита, а разбить на части, сведя к первому случаю.

А толку то? Они все взаимосвязаны и перезагрузить дин из них будет не просто. ООП — это хреновая парадигма для подобных решений. По сему возможность перезагрузить одну сборку один фиг очень полезна.

VD>>На мой взгляд главный недостаток немерла — низкая скорость компиляции.
А>А это не про скорость компиляции, а про скорость развертывания — деплоймент.
А>Компиляция никуда не девается.

Но я смогу, например, разбить функционал по сборкам и перезагружать только одну, измененную.

А>>>Конечно, было бы хорошо иметь меньше ограничений, но и в текущем виде многими считается одним из существенных преимуществ Visual Studio над другими IDE.

VD>>Если многими, то тебе не составит труда дать ссылок на подобные мнения?
А>http://stackoverflow.com/questions/4303599/edit-and-continue-on-gdb
А>Вот цитата по ссылке
А>

А>my experience says it's the first thing MSVC users mention when asked "why not switch to Eclipse and gcc/gdb"

Вообще-то это заметка о MC VC, а не дотнете. Ну, да ладно. Раз! А где два и три? Или один это и есть многие?

Да и где там сказано, что это киллер-фича? Да, мужик хочет такую же на линуксе. С этим не поспоришь. А в MS VC хотелось бы иметь кросплатформность. И что?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Аноним, Вы писали:

VD>Да без разница какой сложности инициализирующее значение.
Ну как это без разницы, когда кто-то недавно заявлял, что значение переменной можно поменять и без Edit and Continue во время отладки.

VD>Edit and continue — это когда код меняется во время отладки. Он при этом перекомпилируется.
Вот именно.

VD>А проблему с лямбдами решить как раз довольно не сложно.
Вот-вот.

VD>Это реальное решение реальной задачи. Лишь бы он работал.
Это еще одно решение. И не самое выгодное.

VD>Не факт. В деплоймент могут включаться разные долгие операции вроде настройки БД
Тогда это уже не небольшой проект, и что мешает настройку БД и конкурирование фреймворков проводить отдельным деплойментом? Правильно ничего. Долгонастраиваемые вещи деплоим отдельно, а текущую разработку отдельно.
В качестве дополнительного плюса, получаем увеличившуюся масштабируемость проекта.

VD>А толку то? Они все взаимосвязаны и перезагрузить дин из них будет не просто.
WCF и отдельные AppDomain вообще никаких проблем.

VD>ООП — это хреновая парадигма для подобных решений.
Как раз наиболее подходящая. Уже в теме появились варианты решений полностью программные, типа Orchard CMS
Интерфейсы, фасады, моки все это отлично вписывается в подобные решения.

VD>Но я смогу, например, разбить функционал по сборкам и перезагружать только одну, измененную.
Сборки в отдельные AppDomain и можно точно также перезагружать по отдельности.

А>>>>Конечно, было бы хорошо иметь меньше ограничений, но и в текущем виде многими считается одним из существенных преимуществ Visual Studio над другими IDE.

VD>Вообще-то это заметка о MC VC, а не дотнете.
VC часть Visual Studio. Потом причем тут в этом вопросе вообще дотнет, когда сравниваются IDE.

VD>А где два и три? Или один это и есть многие?
В качестве упражнения в гугле можно набрать "Edit and Continue" java, "Edit and Continue" apple и т.д.

VD>Да и где там сказано, что это киллер-фича?
Повторяю

it's the first thing

Это синоним киллер фичи. Ибо чаще всего именно их приводят в пример первыми при сравнении двух IDE.

VD>А в MS VC хотелось бы иметь кросплатформность.
В IDE Visual C, конечно есть кросплатформенность.
Не особо трудно из нее компилить хоть под ARM, да и отлаживать можно удаленно.
Или надо чтобы Visual C, запускалось под Wine?

Здравствуйте, Аноним, Вы писали:

VD>>А в MS VC хотелось бы иметь кросплатформность.
А>В IDE Visual C, конечно есть кросплатформенность.

Ладно. Кормить троллей в мои планы не входит. Адью!

Здравствуйте, achmed, Вы писали:
A>То что вы реализовали есть в Orchard CMS, но без перестроения контейнера. Решение основано на Autofac IoC, конкретно с помощью вложенных Scope.
A>Объекты в контейнере по Scope делятся на три типа: корневой, модульный, все остальные (создаваемые на каждый запрос, на каждый inject).
A>Корневые объекты загружаются в контейнер при старте приложения и не выгружаются до конца работы. Модульные объекты загружаются при старте приложения, при включении/отключении плагина и при перекомпиляции модуля. Контроллеры относятся к модульным объектам. Когда происходит перекомпиляция Scope уровня Module уничтожается и создается заново, то же самое происходит при загрузке/выгрузке плагинов. Такое подход избавляет от заказа солнца вручную

Спасибо, не знал об этом.

Почитал об архитектуре этого решения — сделано достаточно интересно. У меня, кстати, первоначально была такая же идея, сделать настоящий фреймворк с модулями и прочим.

Однако тут есть ряд недостатков:
1. Изменения подгружаются только внутри модулей, и то, видимо, не всегда: (In some cases, these changes require an ASP.NET AppDomain restart (e.g. a new version of a module assembly needs to be loaded). Orchard detects these situations and forces an ASP.NET AppDomain restart.)
2. Пользователя привязывают к одному контейнеру и конкретной архитектуре. Текущий проект на это решение не переведёшь.
3. Решение не общее, а следственно не подходит для любого сайта. Думаю, что там сейчас вообще проблемно отделить всю эту инфраструктуру от Orchard, хотя это и не самое главное.
4. Как минимум это решение требует больше трудозатрат со стороны программиста (сравни с добавлением одной строчки в global.asax.cs)

Мой же проект умеет всё что и этот, но при этом лишён его недостатков:
1. Не привязан к конкретному IoC контейнеру
2. Не привязан к архитектуре
3. Изменять в проекте можно абсолютно всё, главное чтобы он потом скомпилировался
4. И что, по-моему, самое главное — он абсолютно прозрачен для программиста. О нём не нужно думать, его не видно (если специально не следить), он просто работает сам по себе.

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

Здравствуйте, ionoy, Вы писали:

I>Спасибо, не знал об этом.

I>Почитал об архитектуре этого решения — сделано достаточно интересно. У меня, кстати, первоначально была такая же идея, сделать настоящий фреймворк с модулями и прочим.

I>Однако тут есть ряд недостатков:
I>1. Изменения подгружаются только внутри модулей, и то, видимо, не всегда: (In some cases, these changes require an ASP.NET AppDomain restart (e.g. a new version of a module assembly needs to be loaded). Orchard detects these situations and forces an ASP.NET AppDomain restart.)

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

I>2. Пользователя привязывают к одному контейнеру и конкретной архитектуре. Текущий проект на это решение не переведёшь.

Это да, на орчард не так то просто перевести готовое решение

I>3. Решение не общее, а следственно не подходит для любого сайта. Думаю, что там сейчас вообще проблемно отделить всю эту инфраструктуру от Orchard, хотя это и не самое главное.
I>4. Как минимум это решение требует больше трудозатрат со стороны программиста (сравни с добавлением одной строчки в global.asax.cs)

ну что сказать, здОрово

I>Мой же проект умеет всё что и этот, но при этом лишён его недостатков:
I>1. Не привязан к конкретному IoC контейнеру
I>2. Не привязан к архитектуре
I>3. Изменять в проекте можно абсолютно всё, главное чтобы он потом скомпилировался
I>4. И что, по-моему, самое главное — он абсолютно прозрачен для программиста. О нём не нужно думать, его не видно (если специально не следить), он просто работает сам по себе.

I>Нисколько не хочу принизить достижение парней из команды Orchard, там видимо реально крутые парни сидят. Думаю, конкретно для CMS их механизм подходит даже лучше, так как вносит в проект логическую структуру.

парни очень крутые работая с Orchard много нового узнал

I>Но тем не менее эта штука очень специфична и для общего решения имхо не подходит.

Здравствуйте, Аноним, Вы писали:

>> Тем не менее она заметно поднимает производительность труда программиста.
>> Неоднократно встречал просьбы в интернете сделать поддержку для GDB, GCC, Java и т.д.


Справедливости ради замечу, что еще в Java1.4 была таехнология HotSwap, которая делала почти то-же, что Edit&Continue, и большинство IDE ее поддерживает. Единственное отличие -- изменения применяться только при следующем вызове метода! А так, то-же самое.