Структура и развертывание веб-приложений

Question

Наш продукт является веб-приложением ASP.Net. В настоящее время мы используем проекты веб-сайтов в Visual Studio, но уже давно изучаем возможности использования проектов веб-приложений. В настоящее время я изучаю их, чтобы мы могли улучшить наш процесс развертывания.

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

Рассматривая переход к проектам веб-приложений в Visual Studio, мы надеялись создать базовый проект, затем создать клиентские проекты и настроить ссылки на базу. Кажется, эта структура работает нормально, но когда мы пытаемся развернуть приложение из клиентского проекта с использованием MSDeploy, публикуется только dll с базового веб-сайта. Это хорошо для некоторых вещей, ссылки на скомпилированный код полезны, но есть другие элементы, такие как изображения, страницы js, htm и т. Д., Которые по-прежнему являются исходными и требуются для работы клиентского приложения. Нам нужно больше, чем скомпилированный код с нашего базового веб-сайта.

При всем этом, я могу придумать несколько вариантов здесь:

1. Продолжить развертывание в 2 этапа. Сначала базовый веб-сайт, затем клиентский веб-сайт для создания полного продукта.
2. Изменение процесса развертывания для копирования необходимых исходных файлов из базового проекта
3. Перепроектируйте нашу модель для поддержки этих базовых отношений с клиентом другим способом. Не совсем уверен, как это будет работать, и будет наименее жизнеспособным вариантом.
4. ??

Есть ли другой вариант, который мне не хватает? Я делаю что-то не так с тем, как я настраиваю свои проекты? Можно ли сделать ссылку на веб-приложение на другое веб-приложение помимо совместного использования скомпилированного кода? Если это так, почему бы вам не использовать библиотеку общих классов? Или, может быть, мне чего-то не хватает в процессе MS Deploy?

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

Обновление: процесс двойного развертывания работает, но чувствует себя немного хитрым. Любой другой ввод?

Answer 1

Используя WebResource сборки, вы можете добавить CSS / JS / некоторый другой файл в качестве ссылки вместе с кодом, т. Е. Вашей базовой библиотекой DLL.

Если вы правы, вы можете добавить этот WebResource в свой базовый проект, затемпо ссылке ниже.

http://support.microsoft.com/kb/910442

Подобным образом большинство сторонних инструментов получат доступ к своим файлам CSS и JS.

Попробуйте это.Надеюсь, это поможет.

Answer 2

Если я правильно понял ваш вопрос, вы хотели бы опубликовать также элементы, которые не скомпилированы (htm, JS, изображения и т. Д.).

Итак, каждый файл в обозревателе решенийВкладка имеет свои собственные свойства (доступ к которым осуществляется клавишей F4), которые позволяют выбрать действие сборки (например, compile -> вставит элемент в DLL, если это применимо, content -> скопирует файл «как есть» в выходной каталог).

Я думаю, что искомым решением может быть действие сборки "content" с параметром "копировать в выходной каталог", установленным на "копировать, если новее".

Answer 3

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

Если это скомпилированный код, правильный способ - извлечь эти классы из их собственного пространства имен и сборки и совместно использовать DLL между проектами. При рефакторинге следуйте принципам OO и SOLID.

Если вы делитесь контентом (js, htm, images, css), у вас есть несколько вариантов здесь. Вы можете создать отдельный виртуальный каталог для контента и ссылаться на него с помощью абсолютного URL. Это помогает, потому что в дальнейшем, если вы когда-нибудь захотите выделить проект на свой собственный веб-сайт в IIS, вам не придется изменять URL-адреса содержимого. Вы также можете разместить весь контент на своем так называемом базовом веб-сайте, а затем ссылаться на контент в других проектах, используя относительный путь относительно базового веб-сайта.

С другой стороны, если вы хотите совместно использовать пользовательские элементы управления ASP.NET или представления ASP.NET MVC, лучше создать отдельный элемент в каждом проекте. Это не обязательно означает, что в этом пути есть отдельный физический файл - вы также можете добавлять в проект .NET в Visual Studio элементы, которые являются только ссылочными ссылками.

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

Я бы также рассмотрел веб-сайты (виртуальные каталоги), созданные в IIS, и рассмотрел бы их размещение, если это имеет смысл. И проверка пулов приложений (как отдельных, так и общих) также не причинит вреда.

Наконец, это старый вопрос. Пожалуйста, поделитесь, если вы уже реализовали успешную стратегию.

Answer 4

Как сайт «делится» между клиентами?Каждый клиент в конечном итоге получает свой сайт (IP-адрес и т. Д.), Или они заходят на один и тот же сайт, но получают разные функциональные возможности?Вы можете захотеть добавить ВСЕ функции в один проект, а затем включить / отключить функцию через настройки.