Предположим, у вас есть два отдельных проекта веб-приложения ASP.NET, которым необходимо использовать общий MasterPage.
Как лучше всего использовать MasterPage в разных проектах без дублирования кода? Желательно без использования системы контроля версий или взлома файловой системы.
Я пытаюсь добиться того же. Я рассматриваю несколько решений, но думаю, что использование виртуального каталога, вероятно, лучший способ поделиться главными страницами.
Вот пара источников, на которые вы можете посмотреть.
Третий пункт в конце статьи рассказывает о возможных способах совместного использования мастер-страниц.
Из статьи К. Скотта Аллена ASP.Net Master Pages: Tips, Tricks, and Traps на «Совместное использование мастер-страниц»:
Первая альтернатива - скопировать общие файлы главной страницы в одно место на веб-сервере IIS. Затем каждое приложение может создать виртуальный каталог в качестве подкаталога и указать виртуальный каталог на реальный каталог главных страниц. Затем приложения могут установить для свойства MasterPageFile страницы имя виртуального каталога плюс имя файла главной страницы. Когда мы перетаскиваем обновленный файл главной страницы в реальный каталог, новая главная страница сразу же появляется во всех приложениях.
Второй подход - использовать систему контроля версий для совместного использования набора файлов главной страницы в нескольких проектах. Большинство систем контроля версий / систем контроля версий поддерживают некоторый уровень функциональности «совместного использования», когда файл или папка могут появляться в нескольких проектах. Когда разработчик регистрирует обновленный файл главной страницы, другие проекты немедленно увидят изменение (хотя это поведение обычно настраивается). При производстве и тестировании каждое приложение необходимо будет повторно развернуть, чтобы появилась главная страница обновления.
Наконец, VirtualPathProvider в ASP.NET 2.0 может обслуживать файлы, которых нет в файловой системе. С VirtualPathProvider набор главных страниц может жить в таблицах базы данных, которые используют все приложения. Прекрасную статью о VirutalPathProvider см. В разделе «Виртуализация доступа к контенту: обслуживание вашего Интернета Сайт из ZIP-файла ».
Сохраните первичную копию в системе управления версиями, и пусть ваша система управления версиями позаботится об этом.
Предположим, вы можете создать общий репозиторий для всех своих проектов (например, общую папку в дереве управления версиями), вы можете добавить главные страницы в виде ссылок, используя относительные пути.
Однако IIRC, Visual Studio делает локальные копии файлов, добавленных по внешним путям. Возможно, вам придется отредактировать текст решения / файла проекта, чтобы добавить связанные файлы.
Это, конечно, предполагает, что вы используете формат «Веб-приложение». Старые VS «Веб-сайты» не имеют файлов проекта и полагаются на то, что все файлы находятся в папке сайта.
AFAIK нет элегантного способа сделать то, что вы ищете ... VS всегда будет копировать его.
Я думаю, если честно, это может быть не самая лучшая идея ... Очевидно, вы хотите поделиться самым низким общим кодом, но целой MasterPage? .. Похоже, у вас могут возникнуть проблемы, поскольку одно незначительное изменение может оказать такое влияние на один или больше приложений ..
Вместо этого я бы предложил разделить хорошие функциональные возможности на компоненты / элементы управления и развернуть их.
Я не понимаю, почему вы хотите иметь одинаковую разметку для разных проектов, если да, я не знаю простого способа.
Однако с кодом, очевидно, вы можете написать файл кода, который наследуется от
System.Web.UI.MasterPage
Добавьте туда любую логику, какую хотите, на все свои мастер-страницы. Создайте ее как свою потрясающую dll, а затем просто включите ее в свои проекты.
Используйте символическую ссылку:
Символьная ссылка - это объект файловой системы, указывающий на другой объект файловой системы. Указанный объект называется целью. Символические ссылки прозрачны для пользователей; ссылки отображаются как обычные файлы или каталоги и могут использоваться пользователем или приложением точно так же.
