Comments 18
Я один не использую web.config ни для чего кроме независимых от окружения настроек? Мне вообще не ясно, что в 2015-ом году логин и пароль к базе делают в файле, лежащем в системе контроля версий. В vNext это наконец-то поправили, появился отдельный config.json/
Если речь идет о логине и пароле к базе девелоперского окружения — то почему бы и нет? А вот логин с паролем от PROD, действительно, лучше хранить где-нибудь в другом месте…
Если речь идет о логине и пароле к базе девелоперского окружения — то почему бы и нет?.То есть, если у вас там, напрример, 3 зависимости по сервисам (база, Redis, Solr/Sphinx/ElasticSearch/whatever), то каждый девелопер либо должен обеспечить к ним одинаковые реквизиты доступа, либо иметь проблемы с merge, да? Во всех цивилизованных web-фреймворках люди в систему контроля версий кладут какой-нибудь config.example.json и только ASP.NET такой особенный. А всё почему? Потому зло под названием что IIS.
- Если сервер DB хорошо изолирован от доступа откуда не надо, то само по себе хранение логина и пароля к нему в конфиге и затем в системе контроля версий большой проблемы не создаёт.
- Но если условие из пункта 1 не выполняется, то чуть ли не любой элемент настроек из web.config можно вынести в отдельный файл через configSource, и этот файл держать локально там, где надо, не загружая его в репозиторий.
Скажите, а вам удалось запустить трансформы локально? Т.е. чтобы при переключении конфигурации сборки в студии и нажатии F5 запускался веб-проект, сконфигурированный соответствующим образом?
Мне удавалось. Правда, для этого требуется вообще удалить web.config из системы контроля версий, и добавить в проект задачу по его сборке из файлов web.common.config и web.$(Configuration).config, благо это несложно.
А нет у студии интерфейса чтоб из повершела дернуть на постбилде?
Как ни исхитряйся — а web.config всегда будет использоваться лежащий в папке проекта. Просто потому что студия создает в IIS виртуальную директорию, напрямую указывающую на эту самую папку.
Это делается, к примеру, чтобы можно было редактировать .aspx и .cshtml-файлы без остановки отладки и пересборки проекта. Как по мне, довольно сомнительная польза — но так сложилось исторически.
Это делается, к примеру, чтобы можно было редактировать .aspx и .cshtml-файлы без остановки отладки и пересборки проекта. Как по мне, довольно сомнительная польза — но так сложилось исторически.
Т. е. получаем развесистую кучу непонятных левых файлов. Ущербность этого решения подтверждается тем, что в vNext перешли на нормальное, выкинув заодно зависимость от IIS.
Чем же вам так не угодил IIS ??!? Отличный сервер, нормально конфигурируется одним файлом приложения. Пароль к бд зашифровать кстати можно, уже 9 лет как.
IIS не угодил своим монополизмом, неповоротливостью и архаичностью (обновлять ОС ради поддержки вебсокетов? серьёзно?) У той же Java EE серверов приложений только сертифицированных больше 20 штук. IIS тормозил развитие ASP.NET с момента появления этого самого ASP.NET. И да, у меня с IIS проблем было больше чем с Mono.
Более 7 лет имею дело с IIS, начиная с 6-ой, заканчивая 8-ой. Имеются свои нюансы и тонкости, но проблем нет. Что я делаю не так? При чём тут Java EE? Обновлять ОС ради поддержки вебсокетов, да. А в чём проблема?
Проблема в том, что к каждой новой ОС от Microsoft надо привыкать заново. И когда ты ненавидишь некоторую версию ОС — а нужная версия IIS работает только на ней…
Имеются свои нюансы и тонкости, но проблем нет.
Есть вещи, которые принципиально не исправляются. Например, если вы решили зачем-то сделать лонг-поллинг и в асинхронном обработчике ждёте события, которые приходят, скажем, из MQ-очереди или Redis, и подключения должны быть активны постоянно, то при наличии активных подключений AppDomain и код никогда не будет выгружен. И узнать о перезапуске сайта с тем, чтобы хотя бы вручную выйти из этих обработчиков вы никак не можете, поскольку все события выгрузки IIS делает после того как отработал последний из них. Получаем замкнутый круг со старой версией сайта, которая будет висеть до последнего подключения, что может продолжаться часы (напомню, это лонг-поллинг).
Это нормально решается средствами OWIN, когда используется Self-Host (срабатывает событие disposing хоста и можно спокойно доделать свои дела и завершиться). Но не в IIS. В IIS проблема не решается никак. Вообще. В данном конкретном случае пришлось выносить в отдельный процесс, использующий HttpListener. Если бы архитектура ASP.NET не была изначально гвоздями приколочена к IIS, его бы вообще не использовали, давно написав managed-сервера вокруг HttpListener/http.sys или вообще поверх сокетов, как в случае NOwin, который в ряде случаев работает быстрее HttpListener.
IIS тормозил все эти годы развитие ASP.NET. Сейчас, когда разогнали старое руководство, в Microsoft это наконец-то поняли и делают по уму.
При чём тут Java EE
Java EE приведена в качестве примера того, как в других местах делают нормально.
А в чём проблема?
0) во всех остальных программных платформах такой необходимости не возникает, это фишка дотнетовская такая (да, я понимаю, что IIS — не настоящий веб-сервер и пользуется http.sys, встроеннным в ядро)
1) нужно приобрести новые лицензии для сервера, который и так работал
2) нужно переобучить админа, так как что-то обязательно поменялось
3) после обновления ОС что-нибудь обязательно перестаёт нормально работать по причинам совместимости
4) более свежие ОС от MS жрут больше системных ресурсов
В целом я согласен, что IIS мог бы быть лучше. При чём на порядки лучше. Но не согласен с тем, что своих задач он не решает, учитывая сколько проектов было поднято в моём опыте, которые до сих пор отлично справляются со своими задачами. На счёт невыгружаемого домена из-за длительных подключений, это больше вопрос архитектуры и баланса нагрузки, по крайне мере я с такой неразрешимой проблемой не сталкивался. Все проблемы на IIS решались. Все. Без исключения.
Конечно сегодня OWIN выглядит привлекательно, и архитектура ASP.NET уже отвязывается от IIS это видно по vNext, так что тенденции положительные, не обязательно валить всё на IIS :)
0) во всех остальных программных платформах такой необходимости не возникает, это фишка дотнетовская такая (да, я понимаю, что IIS — не настоящий веб-сервер и пользуется http.sys, встроеннным в ядро)
1) нужно приобрести новые лицензии для сервера, который и так работал
2) нужно переобучить админа, так как что-то обязательно поменялось
3) после обновления ОС что-нибудь обязательно перестаёт нормально работать по причинам совместимости
4) более свежие ОС от MS жрут больше системных ресурсов
0) Нет смысла сравнивать с другими платформами. Всегда есть выбор, я свой сделал, и меня он устраивает.
1) Не вижу проблем, на дворе 2015, все серверы в компании и у клиентов используют 2012 R2, вопрос стоимости лицензий не моя головная боль.
2) Естественно. Это относится ко всем сферам вообще. Постоянно выходят новые версии всего, надо постоянно находиться в режиме обучения, это хорошо, а не плохо. Опять же, мне неинтересно, если кто-то там хочет один раз что-то выучить и на всю жизнь: больше не читать ни статей, ни книг, и ничего больше не учить.
3) Да. А MS DOS вообще работал 286 компе с 1Мб оперативной памяти :)
Я понимаю ваши претензии, но в целом, они не существенны. По опыту, сегодня я с неразрешимыми проблемами IIS-а не сталкивался. Хотя делал и селфхосты, и даже когда-то пытался поднять ASP.NET без окружения IIS-а, сейчас это стало реальностью.
Конечно сегодня OWIN выглядит привлекательно, и архитектура ASP.NET уже отвязывается от IIS это видно по vNext, так что тенденции положительные, не обязательно валить всё на IIS :)
0) во всех остальных программных платформах такой необходимости не возникает, это фишка дотнетовская такая (да, я понимаю, что IIS — не настоящий веб-сервер и пользуется http.sys, встроеннным в ядро)
1) нужно приобрести новые лицензии для сервера, который и так работал
2) нужно переобучить админа, так как что-то обязательно поменялось
3) после обновления ОС что-нибудь обязательно перестаёт нормально работать по причинам совместимости
4) более свежие ОС от MS жрут больше системных ресурсов
0) Нет смысла сравнивать с другими платформами. Всегда есть выбор, я свой сделал, и меня он устраивает.
1) Не вижу проблем, на дворе 2015, все серверы в компании и у клиентов используют 2012 R2, вопрос стоимости лицензий не моя головная боль.
2) Естественно. Это относится ко всем сферам вообще. Постоянно выходят новые версии всего, надо постоянно находиться в режиме обучения, это хорошо, а не плохо. Опять же, мне неинтересно, если кто-то там хочет один раз что-то выучить и на всю жизнь: больше не читать ни статей, ни книг, и ничего больше не учить.
3) Да. А MS DOS вообще работал 286 компе с 1Мб оперативной памяти :)
Я понимаю ваши претензии, но в целом, они не существенны. По опыту, сегодня я с неразрешимыми проблемами IIS-а не сталкивался. Хотя делал и селфхосты, и даже когда-то пытался поднять ASP.NET без окружения IIS-а, сейчас это стало реальностью.
А чего никто не упомянул про расширение SlowCheetah?
Добавляет такие же трансформации для любого конфига, не только web.config. Добавляется в проект, если правильно помню, через nuget, дополняет контекстное меню конфигов командой Add transform для автоматической генерации заготовок трансформации.
Работает как таск для msbuild. Очень удобно.
Добавляет такие же трансформации для любого конфига, не только web.config. Добавляется в проект, если правильно помню, через nuget, дополняет контекстное меню конфигов командой Add transform для автоматической генерации заготовок трансформации.
Работает как таск для msbuild. Очень удобно.
Sign up to leave a comment.
.NET-разработка: переключения между DEV и PROD-окружениями. Часть первая