Нужно ли кодировать сайты ASP.NET, чтобы они могли жить в VDIR?

Question

В те времена, когда до Web-сервера Visual Studio мы размещали нашего локального разработчика внутри IIS. Если у вас есть версия IIS для рабочей станции, это означает только 1 веб-сайт. Что делать, если вы работаете на нескольких сайтах. Просто: создайте их в VDIR, например, http://localhost/ProjectA, http://localhost/ProjectB.

Жизнь в VDIR звучит не так уж и сложно. Убедитесь, что все ваши изображения / CSS / ссылки являются относительными путями, часто используйте "~". Похоже, хорошая практика. Жесткое кодирование изображений и т. Д., Поэтому они работают только тогда, когда приложение подается из «/», звучит как плохая практика.

Везде, где вам нужно создать ссылку, есть некоторые нюансы (в основном это не распространенные сценарии):

• например; PROD: http://prodserver.com/images/up.jpg -> DEV: http://localhost/ProjectA/images/up.jpg
• ссылки / изображения в письмах
• flash / javascript / silverlight запрашивает данные с сервера, который содержит ссылки на изображения
• Полная ссылка на IPP PayPal (страница PayPal также публикует свой ответ)

Итак ... Ты это делаешь? Преимущества недостатки? Любые другие ошибки, которые я пропустил?

Answer 1

Короче говоря, да . Недостатки невыполнения перевешивают преимущества. Я на самом деле думаю, что ваши первые две точки также могут быть в основном смягчены использованием относительных к приложению путей ("~"), но, тем не менее, некоторые сценарии, такие как "уровень интеграции" (например, PayPal), могут действительно оказаться сложными.

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

Некоторая предыстория / контекст: Моя текущая производственная рабочая среда в любом случае почти всегда является виртуальным каталогом, поэтому я делаю это по необходимости. И у меня никогда не было проблем, когда приложение создавалось как веб-сайт корневого уровня. Это, конечно, было бы не так, если бы все было наоборот.

Answer 2

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

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

Мне нравится обработчик идей, который отвечает на "globalvars.ashx" (или что-то подобное; есть много способов справиться с этим), который динамически генерирует (и позволяет кэшировать) свойства, касающиеся глобальных свойств приложения.

Скажем, обработчик, отвечающий за globalvars.ashx, записывает результат примерно так:

String.Format("var ApplicationProperties = {{ RootPath:{0} }};", Request.ApplicationPath);

Ваше поведение JS теоретически может ссылаться на этот объект свойства в любой точке через ApplicationProperties.RootPath.