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

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

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

Answer 3

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

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

Я думаю, что действие по компоновке "content" с опцией "copy to output directory", установленной в "copy if newer", может быть решением, которое вы ищете.

Answer 4

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

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

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

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

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

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

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