Возможно ли создать отдельные DLL с проектом MVC?

У нас есть большой проект, разработанный в Asp.net MVC5. Наши модели и бизнес-логика определяются в отдельных библиотеках классов. Теперь нам нужно добавить еще один модуль в существующий проект, но нам нужна отдельная dll.

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

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

Ответ 1

Из вашего описания вы говорите, что проекты совместно используют файлы CSS и JS. Это заставляет меня поверить, что вы говорите о отдельном веб-сайте MVC (возможно, на более крупном корпоративном веб-сайте). Это может быть проще всего с использованием областей. Если вы не знакомы с областями, прочитайте следующее: https://msdn.microsoft.com/en-us/library/ee671793(VS.100).aspx

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

Если вы не хотите использовать области и вместо этого хотите создать другой проект MVC в том же решении, вы тоже можете это сделать. Вы можете щелкнуть правой кнопкой мыши по решению, добавить новый проект > веб-приложение ASP.NET > MVC для добавления проекта. Чтобы разделить файлы JS и CSS между этими двумя проектами MVC, вам нужно будет создать новую папку решений (щелкните правой кнопкой мыши > Добавить новую папку решений) и переместите файлы ресурсов в эту папку. Внутри каждого проекта MVC в вашем решении вы добавите существующие элементы и выберите эти файлы ресурсов js/css. Таким образом, если вы измените файл css, он будет отражен в обоих проектах.

Для получения дополнительной информации прочитайте следующее:

Как вы совместно используете скрипты из нескольких проектов в одном решении?

Ответ 2

Да, вы можете просто добавить логические классы в другой проект библиотеки классов (у вас может быть столько, сколько хотите), а затем добавить ссылки на эти библиотеки классов в проект mvc. Не забудьте импортировать классы после кода

Изменить: Я предполагаю, что вы используете Visual Studio, если да, вы можете перейти в File → Create Project, это создаст другой проект в том же решении.

Ответ 3

Я не знаю, пытались ли вы с Managed Extensibility Framework (MEF) или нет.. этот framework работает так, как вам нужно... Я думаю, что ниже ссылка поможет вам больше

Расширение ASP.NET MVC с помощью MEF

Как интегрировать MEF с ASP.NET MVC 4 и ASP.NET Web API

http://www.codeproject.com/Articles/167321/MEF-with-ASP-NET-Hello-World

Ответ 4

Я могу предложить вам два способа организации вашего мультимодульного проекта.

Вариант 1 - Создать область для каждого модуля в рамках одного веб-проекта

Один из способов сделать это - создать отдельный Area в рамках одного и того же проекта MVC. Таким образом, каждый модуль будет иметь отдельную область, с отдельными контроллерами, представлениями, сценариями и т.д. Но,
(1) Это все равно будет создавать один dll для всего проекта MVC
(2) Совместное использование файлов в разных областях может быть не очень легким в некоторых сценариях (вы можете сохранить все сценарии для всех модулей в одном общем каталоге)

Вариант 2. Создайте библиотеку классов для каждого модуля, слейте после сборки

Другой способ - создать один проект class library для каждого модуля. Добавьте ссылку на System.Web.Mvc и другие библиотеки, чтобы она могла иметь controllers и т.д. Создавайте свои собственные представления, скрипты и другие папки и заполняйте файлы по мере необходимости.

Теперь все ваши модули будут создаваться как отдельные проекты, с файлом dll и javasvript s, html s, css s, изображениями и т.д. Чтобы все они работали как один web application вы можете создать (только один) MVC веб-проект, который перейдет в виртуальный каталог IIS и будет опубликован как web.

Чтобы использовать все ваши отдельные модули из одного и того же веб-сайта, вы можете написать post build события во всех этих библиотеках скопировать артефакты (dll, скрипты и т.д.) в основную сеть, в соответствующие папки (dll to\bin, javascript to\scripts и т.д.). Таким образом, после успешной сборки все артефакты доступны в одном и том же веб-проекте и могут быть развернуты как единая сеть со всеми модулями. Ваши сценарии построения сборки должны выглядеть примерно так:

XCOPY "$(ProjectDir)$(OutDir)*.*" "$(ProjectDir)..\YourMainWebDirectory\Bin\" /Y
XCOPY "$(ProjectDir)Content"  "$(ProjectDir)..\YourMainWebDirectory\Content\"  /S /Y
XCOPY "$(ProjectDir)Scripts"  "$(ProjectDir)..\YourMainWebDirectory\Scripts\"  /S /Y
XCOPY "$(ProjectDir)Views"  "$(ProjectDir)..\YourMainWebDirectory\Views\"  /S /Y
XCOPY "$(ProjectDir)Images"  "$(ProjectDir)..\YourMainWebDirectory\Images\"  /S /Y

Теперь,
(1) У вас есть отдельные dll для отдельных модулей
(2) Можно напрямую обмениваться скриптами и другими файлами, так как они будут в одном месте (после сборки)
(3) Если вы решили удалить определенный модуль из Интернета, просто удалите событие post build из этого модуля (проекта), не затрагивая ничего другого. Вы можете добавить это обратно в любое удобное для вас время.

Ваш общий solution будет выглядеть как

Module01.csproj => post build copy to main
    \Controllers
    \Scripts
    \Views
    \Contents
    \Images

Module02.csproj => post build copy to main
    \Controllers
    \Scripts
    \Views
    \Contents
    \Images

Models.csproj
    \...

Application.csproj
    \...

Main.Web.csproj => main web application hosted in IIS
    \Controllers
    \Scripts
    \Views
    \Contents
    \Images

Ответ 5

Другие люди опубликовали ответы на вопрос об использовании Районов. Районы велики, хороши и полезны. Они действительно приносят пользу структуре проекта.

Этот модуль также разделяет большинство javascripts, css файлов и другого файла

Название вашего вопроса о DLL, но я подозреваю, что ресурсы на стороне клиента являются главной проблемой.

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

Параметры управления пакетами Front-end расширены для ASP.NET 5. В дополнение к традиционному менеджеру пакетов NuGet теперь поддерживаются Bower и NPM. Например, рассмотрим, как эта статья демонстрирует установку jQuery через NPM. Вот еще одна хорошая статья о настройке NPM, Bower и Gulp в Visual Studio.

Что делать: возьмите свой существующий клиентский код и создайте пользовательский пакет NPM или Bower, а затем используйте этот пакет из одного или нескольких проектов Asp.NET.