Які можливі недоліки веб-сайту IIS 7, що має перехід NTFS як веб-корінь?

13

Я намагаюся придумати спосіб розгортання коду ASP.NET з якомога меншим порушенням сайту. Одна з думок полягала в тому, щоб створити сайт, який обслуговуватиметься з переходу NTFS, c:\www\example.comде

c:\www\example.com -> c:\www\example.com_r1234

Потім, коли новий код розгортається, він копіюється c:\www\site.com_r1235і з'єднання повторно передається

c:\www\example.com -> c:\www\example.com_r1235

Отже, моє питання полягає в тому, що це може вплинути на поточні запити в IIS? Які ще недоліки можуть мати це з точки зору реакції IIS на зміну (якщо вона є)? Чи буде це настільки ж безпроблемним для кінцевого користувача сайту, як я сподіваюся?

(Я розглядав можливість зміни веб-корінця сайту через командний рядок, але мені дуже не подобається ідея перенастроювання IIS через непотрібний домен додатка чи пул додатків, який може статися, але я не знаю багато про що що відбувається, коли налаштований фізичний шлях веб-сайту змінюється під час навантаження)

Щоб було зрозуміло, моя єдина турбота тут - це досвід моїх кінцевих користувачів. Моя мета - уникнути збурень для них, а не зручності для мене.

— jayrdub
джерело

1

Скиньте веб-корінь. Будь-яка переробка (не думаю, що це було б) і перезавантаження пулу додатків тоді а), ймовірно, не є "непотрібною", і б) допомагають робочому процесу підтримувати реалістичне уявлення про стан його вмісту та кеш-пам'яті. Це розумне рішення, звичайно, але розумне рідко означає стабільність. Дізнайтеся, що робить більшість людей, тоді це зробіть.

— TristanK

Це чудове запитання, я довго шукав відповіді на це. Все, що я коли-небудь бачив, це або розгортання розгортання під балансиром завантаження (якого у мене немає), або проста копія / svn файлів у веб-кореневій (що мені не подобається).

— jayrdub

1

Отже, спробуйте спочатку перенаправити веб-корінь.

— TristanK

3

спосіб розгортання коду ASP.NET з якомога меншим порушенням сайту.

Схоже, що ця мета та запропоноване рішення не узгоджуються, оскільки тепер у вас є маса додаткової роботи або сценаріїв для кожного розгортання.

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

— Джоел Коель
джерело

Ця мережева робота призведе до того, що артефакти сайту знаходяться занадто довго в неоднозначності. Саме такої ситуації я намагаюся уникати. Я намагаюся усунути час, коли збірки під веб-коренею мають різні версії.

— jayrdub

1

"Додаткова робота та сценарії" не викликає занепокоєння, ми повністю автоматизовані

— jayrdub

Я вважаю, що справедливо, збурення та потрібна робота насправді не те саме

— Марк Хендерсон,

Порушення кінцевого користувача мого сайту - це те, про що я маю на увазі

— jayrdub

2

Я створив папку за своїм веб-корінтом під назвою _images

C:\DEV\_IMAGES

потім скопіював у нього купу файлів gif. Потім я створив символічне посилання NTFS в моєму корені за допомогою

C:\DEV\PROJECT\ROOT mklink /D webimages ..\_images

У Visual studio 2010 я "Показати всі файли" потім оновити ... і включити нові "веб-зображення" у свій проект. Зараз я можу вказати на ...

img src='webimages/icon.gif'

Коли я запускаю додаток, він працює чудово і на моїй локальній машині.

Я не знаю, чи працює він на реальному сервері (IIS 7), поки інфраструктура не впорається з цим, чи хтось знає якісь питання, чому це не працює у виробництві ??

Я вважаю, що права існують, і якщо так, то який прекрасний спосіб спростити обмін папками (усіх типів) між веб-додатками.

Я ще не намагався це висловити в TFS, тому якщо хтось має відгуки про це, повідомте нам!

— Грег
джерело

0

Це не буде працювати, оскільки IIS може подумати, що web.config змінився іншою програмою. IIS, ймовірно, викине виняток System.Configuration.ConfigurationErrorsException. Я б запропонував написати якийсь сценарій, щоб просто змінити домашній каталог сайту.

— Кори
джерело