Как разделить пользовательские элементы управления между веб-приложениями в ASP.NET?

Question

Этот вопрос является продолжением моего вопроса о совместном использовании ресурсов между веб-приложениями , поскольку я еще не нашел хорошего решения.

У меня есть веб-приложение с пользовательскими элементами управления и ресурсами, которые совместно используются тремя другими веб-приложениями.

Solution
|
+-CommonControlsWebApp
| +- resources
| |  +- images
| |  +- scripts
| |  +- stylesheets
| +- UserControls
| 
+-WebApp1
| 
+-WebApp2
| 
+-WebApp3

Это то, что я знаю так далеко:

• Я не могу скомпилировать CommonControlsWebApp в одну DLL, так как я создаю пользовательские элементы управления. Это возможно только при использовании пользовательских серверных элементов управления, где все находится в файле code-behind. Поэтому мне нужен способ поделиться файлами ascx между четырьмя проектами.
• Копирование файлов из CommonControlsWebApp в три других проекта не приводит к обновлению их файлов в обозревателе решений. При добавлении или переименовании файла в CommonControls мне нужно было бы «добавлять существующие элементы» во всех трех веб-приложениях.
• Переход на модель веб-сайта исправит это, но я беспокоюсь о времени компиляции для WebApp1-3, если я сделаю это.
• «Добавить как ссылку» не работает для каталогов.
• Я мог бы использовать Subversion для обмена файлами между проектами, но я считаю, что это потребовало бы от меня постоянной проверки файлов снова и снова, если я разрабатываю пользовательский элемент управления, который мне нужно протестировать через один из WebApps.

Может ли быть правдой, что ASP.NET не имеет хорошего решения для этого? Как вы, ребята, организуете большие веб-приложения?

Редактировать: Большое спасибо за все ответы. Я сейчас скопирую свои пользовательские элементы управления с событием сборки, а затем посмотрим, успеем ли мы преобразовать их в серверные элементы управления.

Answer 1

То, как мы это делаем в моей нынешней компании, - это убедиться, что CommonControlsWebApp это веб-приложение, а не веб-сайт. Затем вы используете имена папок, которые помогут идентифицировать его как общие, отличные от отдельных веб-приложений. (CommonUserControls вместо просто UserControls)

В других ваших веб-приложениях вы создаете виртуальный каталог для CommonUserControls и т. Д. И добавляете ссылку на файл в CommonControlsWebApp.dll

Для этого требуется, чтобы вы использовали IIS для разработки (не casini), и Visual Studio не поверит, что элементы управления действительно существуют, но он будет работать во время выполнения, и вы можете просто отлично строить только с предупреждениями о blahblah.ascx или Blahblah.master путь неверен.

Если вы используете общие главные страницы и Visual Studio 2008, вам потребуется SP1 для 2008 и использовать __fallback.master в корне отдельных веб-проектов, чтобы перейти в режим разработки.

Тем не менее, я видел это в другой ветке, и я собираюсь разобраться в том, чтобы сделать больше так: http://webproject.scottgu.com/CSharp/UserControls/UserControls.aspx

Answer 2

Вы можете скомпилировать его в dll

Превращение пользовательского элемента управления .ascx в распространяемый пользовательский элемент управления

Краткое описание шагов

Основные шаги, чтобы это произошло являются следующими:

1. Напишите свой пользовательский элемент управления, как обычно, используя Visual Studio дизайнер.
2. Протестируйте его, используя простую страницу, прежде чем пытаться развернуть его.
3. Разверните приложение для его прекомпиляции.
4. захватить сборку пользовательского элемента управления, созданную на этапе развертывания, и вы по существу сделали: у вас есть Пользовательский контроль.
5. Наконец, используйте свой пользовательский элемент управления в других приложениях

Дополнительная информация здесь http://www.nathanblevins.com/Articles/Compile-a-Web-User-Control-into-a-DLL-.Net-c-.aspx

Answer 3

Проверьте этот пост о том, как решить эту проблему.

Основная идея состоит в том, чтобы изменить ваш проект так, чтобы на этапе предварительной сборки он копировал файлы .ascx в подкаталог веб-приложения. Тогда просто обратитесь к этим копиям при их использовании. Конечно, вам также нужно сослаться на сборку UserControls.

Answer 4

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

Используя SourceGear Vault, но вы можете сделать это с любым продуктом управления версиями.

Answer 5

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

К сожалению, у asp.net нет действительно хорошего решения для этого. То же самое относится и к совместному использованию главных страниц.

Answer 6

эй, это не лучший способ сделать что-то, но я привык делать это в моем asp.net 1.1 дня - вы можете попробовать это - перенести ваши пользовательские элементы управления в отдельный проект и опубликовать этот проект как виртуальный каталог под Iis

до тех пор, пока вы не используете codebehind - ваши обновления будут классными (обновляйте только общую папку пользователя)

если вы используете codebehinds - повторно разверните dll пользовательского элемента управления в разные проекты

---

как только вы закончите с этим - отобразите эти пользовательские элементы управления во все проекты, используя их виртуальные пути

проверьте эти ссылки - http://aspadvice.com/blogs/ssmith/archive/2006/10/05/Tip_3A00_-Share-User-Controls-Between-Applications-in-ASP.NET.aspx

И

http://www.123aspx.com/redir.aspx?res=30887

Answer 7

Один из вариантов - попробовать «Добавить существующий», и в появившемся диалоговом окне рядом с кнопкой «ОК» появится стрелка сброса, изменив ее на «Добавить со ссылкой».

Если это не сработает, перепишите элементы управления в качестве пользовательских элементов управления.

Это займет немного времени, но сделает его более удобным в будущем.