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

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

9 голосов
/ 27 марта 2009

У меня есть три проекта веб-приложений, которые используют общую библиотеку пользовательских серверных элементов управления. Совместное использование кода для файлов легко - они компилируются в 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 для включения одинаковых файлов во все три решения. Никто в команде не пробовал этого раньше, поэтому мы не уверены, насколько хорошо это будет работать.

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

Ответы [ 3 ]

2 голосов
/ 27 марта 2009

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

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

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

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

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

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

Недостатки:

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

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

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

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

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

0 голосов
/ 12 сентября 2017

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

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

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

c: \ nuget.exe pack YOURPROJ.csproj -IncludeReferencedProjects -Prop Платформа = AnyCPU -Exclude **. Tt -Exclude **. Txt

...