Наш продукт представляет собой веб-приложение ASP.Net. В настоящее время мы используем проекты веб-сайтов в Visual Studio, но уже довольно давно изучаем проекты веб-приложений. В настоящее время я изучаю их, чтобы мы могли, надеюсь, улучшить процесс развертывания.
У нас есть базовый веб-сайт, общий и общий для разных клиентов, а затем мы расширяем его с помощью клиентских функций в проектах веб-сайта клиента. Клиентские проекты расширяют базу и поэтому полагаются на ее содержимое. Чтобы создать полный продукт, мы сначала развертываем базовый веб-сайт, а затем накладываем его на содержимое из проекта клиента.
В процессе преобразования в проекты веб-приложений в Visual Studio мы надеялись создать базовый проект, затем создать клиентские проекты и установить ссылки на базу. Кажется, что эта структура работает нормально, но когда мы пытаемся развернуть приложение из клиентского проекта с использованием MSDeploy, публикуется только DLL с базового веб-сайта. Это хорошо для некоторых вещей, ссылка на скомпилированный код полезна, но есть другие элементы, такие как изображения, js-страницы, htm и т.д., Которые все еще являются источником, который требуется для функционирования клиентского приложения. Нам нужно больше, чем скомпилированный код с нашего базового веб-сайта.
Чтобы все сказанное, я могу придумать несколько вариантов:
Есть ли другой вариант, который мне не хватает? Я что-то делаю неправильно с тем, как я настраиваю свои проекты? Есть ли еще один способ сделать ссылку на веб-приложение другим веб-приложением, помимо совместного использования скомпилированного кода? Если это так, почему бы вам просто не использовать общую библиотеку классов? Или, может быть, я учу что-то с процессом MS Deploy?
Я открыт для предложений здесь, поскольку я чувствую, что что-то не хватает. Я не думаю, что наша модель для наших веб-приложений слишком уникальна.
Обновление: процесс двойного развертывания действительно работает, но он чувствует себя немного клодгеем. Любой другой вход?
Используя сборку WebResource, вы можете добавить CSS/JS/Some другой файл в качестве ссылки вместе с кодом i.e, вашей базовой DLL проекта.
Если вы правы, вы можете добавить этот WebResource в свой базовый проект, затем перейдите по ссылке ниже.
http://support.microsoft.com/kb/910442
Таким образом, большинство сторонних инструментов получат доступ к своим файлам CSS и JS.
Попробуйте это. Надеюсь, это поможет.
Как сайт "делится" между клиентами? Каждый клиент, в конечном счете, получает другой сайт (IP-адрес и т.д.) Или они регистрируются на одном сайте, но получают разные функции? Вы можете захотеть добавить все функции в один проект, а затем включить/отключить функцию через настройки.
Если я правильно понял ваш вопрос, вы хотите опубликовать также элементы, которые не скомпилированы (htm, JS, изображения и т.д.).
Таким образом, каждый файл на вкладке "Проводник решений" имеет свои собственные свойства (к которому обращается ключ F4), который позволяет вам выбирать действие сборки (например, компиляция → будет вводить элемент в DLL, если это применимо, содержимое → будет копировать файл "как есть" для вывода каталога).
Мне кажется, что решение для сборки "content" с опцией "copy to output directory", установленной в "copy if newer", может быть решением, которое вы ищете.
Я бы тщательно проанализировал, что вы делитесь между проектами и как вы их делитесь.
Если это скомпилированный код, правильным способом является извлечение этих классов в собственное пространство имен и сборка и совместное использование DLL для разных проектов. Убедитесь, что вы выполняете принципы OO и SOLID во время рефакторинга.
Если у вас есть контент (js, htm, images, css), у вас есть несколько вариантов. Вы можете создать отдельный виртуальный каталог для контента и указать свой контент с абсолютным URL-адресом. Это помогает, потому что позже в строке, если вы хотите отделить проект на своем собственном веб-сайте в IIS, вам не нужно менять URL-адреса контента. Вы также можете иметь весь контент на своем так называемом базовом веб-сайте, а затем ссылаться на контент в других проектах, используя относительный путь относительно базового веб-сайта.
С другой стороны, если это пользовательские элементы управления ASP.NET или представления ASP.NET MVC, которые вы хотели бы поделиться, лучше всего создать отдельный элемент в каждом проекте. Это не обязательно означает, что в этом пути есть отдельный физический файл - вы также можете добавлять элементы в .NET-проекте в Visual Studio, которые являются только ссылочными ссылками.
Что касается процесса развертывания, я не думаю, что в проектах веб-сайта есть что-то не так. Проекты веб-сайтов имеют цель, отличную от проектов веб-приложений, главным из которых является то, что вам не нужно собирать свои классы при каждом развертывании кода (при условии, что они находятся в правильных папках приложений). Я бы предложил придерживаться двухэтапного процесса развертывания с проектами веб-сайтов.
Я бы также рассмотрел веб-сайты (виртуальные каталоги), созданные в IIS, и рассмотрел их вложенность, если это имеет смысл. И обзор пулов приложений (будь то отдельный или общий) не повредит.
Наконец, это старый вопрос. Поделитесь, если вы уже реализовали успешную стратегию.