Как совместно использовать общие веб-ресурсы между веб-приложениями в Visual Studio?

у меня есть три проекта веб-приложений, которые имеют общую библиотеку пользовательских серверных элементов управления. Совместное использование кода за файлами легко-они компилируются в dll, которые я ссылаюсь в других проектах, используя ссылку на проект. Но как я могу обрабатывать файлы, такие как JavaScript, таблицы стилей и картинки? Я пытаюсь сделать это "способом Visual Studio", чтобы его было как можно проще понять и отладить.

текущая настройка несколько похожа это:

CommonControlsWebApp
+- CustomControls
+- resources
   +- images
   +- scripts
   +- stylesheets

WebApp1
+- resources*

WebApp2
+- resources*

WebApp3
+- resources*

*) виртуальный каталог в IIS.

виртуальный каталог каждого веб-приложения указывает на каталог ресурсов в моем CommonControlsWebApp. Это настроено в IIS. Visual Studio не может понять эту ссылку, поэтому отладка требует, чтобы я подключился к IIS-процессу вручную.

другим решением может быть включение каждого ресурса в общую dll с помощью WebResourceAttribute. Но это обернется src ссылки на что-то вроде Webresource для.классов AXD?d=GUID при просмотре источника моих веб-страниц, и я боюсь, что это сделает его довольно запутанным для отладки.

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

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

9
asp.net resources visual-studio-2008 web-applications

3 ответов

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

однако, WebResource.источников что является недостатком. Обычно вы можете "отлаживать" URL-адрес с чем-то вроде Firebug, чтобы увидеть, что на самом деле вернулось из запроса, но я согласен, это может быть боль, если что-то работает неправильно. Еще один недостаток - если у вас есть десятки ресурсов для одного серверного элемента управления, особенно если на них ссылаются несколько раз каждый (подумайте о treeview с сотнями небольших изображений на узлах) - тогда URL-адрес может добавить тонну фактических байтов к окончательному выходу HTML.

Если ваш потребности распределения / локализации перевешивают ваши потребности в оптимизации / отладке, я бы рассмотрел вопрос о внедрении ресурсов.

Если нет, то вы определенно можете сделать #3 - копирование всего на свой сайт с помощью Subversion. Проверьте svn Externals для того, чтобы установить его. Немного времени, вложенного в изучение этого сейчас, может сэкономить вам тонны по дороге!

2

Я выбрал простой выход и поместил все свои проекты в одно решение. Затем я создал проект WebUserControlLibrary, в который я поместил все общие элементы управления.

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

copy "$(SolutionDir)WebUserControlLibrary\UserControls\*.ascx"
   "$(ProjectDir)ImportedUserControls\UserControls"

и, конечно же, ссылаться на WebUserControlLibrary из проектов, которые в нем нуждаются.

преимущества этой подход:

  • отладка в Visual studio работает,
  • нет дублирования кода

недостатки:

  • неуклюжим решение :)
  • после изменения .ascx-файл, проект должен быть перестроен. Это означает, что невозможно изменить html и обновить страницу в IE и увидеть результаты напрямую.
2

У меня есть несколько вариантов, чтобы бросить в ведро:

Вариант 1: Используйте общий проект для своих ресурсов: http://rion.io/2017/03/22/sharing-is-caring-using-shared-projects-in-asp-net/

Параметры 2 Преобразуйте библиотеку классов в пакет NuGet. Я не считаю, что вам нужно много делать при упаковке, кроме следующих, чтобы включить все папки и файлы в папку проекта NuGet:

c:\nuget.exe пакет YOURPROJ.csproj-IncludeReferencedProjects-Prop Platform=AnyCPU-Исключить **.TT-исключить **.txt

0