Как использовать разделяемую библиотеку в ASP.Net Core MVC, работающей на IIS

Question

Я изучаю использование ASP.Net Core MVC для некоторых моих новых проектов.Я работаю в команде разработчиков для очень большой организации, и каждый из нас по отдельности пишет множество небольших веб-приложений.Из-за размера нашей организации у нас есть много правил, которым мы должны следовать, и иногда эти правила меняются совершенно вне нашего контроля.Вот что мы использовали в прошлых проектах, все они работали на IIS:

• ASP Classic - Каждая корневая папка IIS имеет общую папку, содержащую множество часто используемых файлов .asp,Эти файлы в основном одинаковы на каждом сервере, но могут указывать на разные базы данных для сред dev / test / prod.Эти библиотечные файлы используются для общих вещей, таких как аутентификация, авторизация, шифрование, отправка электронных писем и т. Д. Каждое приложение будет находиться в одной папке в общей папке и включать такие файлы, как ".. \ shared \ library.asp"

• ASP.Net / MVC - самым близким, что мы могли найти, был GAC.Все говорят, что не следует использовать GAC, но для наших целей он делает именно то, что нам нужно.Мы создали библиотеку DLL и храним ее в GAC каждого веб-сервера.Затем мы помещаем информацию о локальной конфигурации (специфические для среды dev / test / prod) в глобальный web.config каждого сервера IIS.Информация, относящаяся к конкретному приложению, будет храниться в локальном файле web.config этого приложения.

Красота этих двух систем иногда в том, что все меняется, и мы можем просто обновить глобальные библиотеки, икаждое зависящее от них приложение будет адаптироваться к новому коду без перекомпиляции.У нас много приложений, работающих на многих веб-серверах.Это не может быть идеальным, но для наших нужд это работает отлично, учитывая, что правила могут измениться в любой момент, и перекомпиляция каждого приложения будет огромным испытанием.Мы просто должны быть уверены, что никогда не внесем критических изменений в наши библиотеки, что достаточно просто.У нас нет проблем с тем, как это работает.

Теперь перейдем к ASP.Net Core.Есть ли элегантный способ сделать это?Кажется, что Core не поддерживает GAC и не поддерживает web.config.Все хочет использовать appsettings.json.Есть ли способ создать appsettings.json на корневом уровне IIS и установить для него глобальные переменные, такие как environment = "dev", authdatabase = "devsql" и т. Д.?И можем ли мы хранить .Net Core / Standard DLL в общей папке, и чтобы каждое приложение загружало его с помощью пути ".. \ shared \ library.dll"?Самой близкой вещью, которую я мог найти, чтобы сделать это с .Net framework, был GAC, но я на самом деле не нахожу никаких ответов на это с Core.Я ценю любую помощь, спасибо!

Answer 1

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

Обратите внимание, что это точно одна из причин, по которой обычно избегают развертывания GAC.Если вы обновляете зависимость, и в ней содержится критическое изменение (в любом возможном случае), тогда приложения начнут случайным образом прерываться, если вы не будете контролировать это.

Обычно, еслиЧтобы обновить зависимость, необходимо развернуть повторное тестирование каждого приложения, которое зависит от этого, до развертывания обновленного приложения.Вот почему обновления зависимостей (например, через NuGet) - это осознанный выбор, который вам нужно сделать.

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

Это на самом деле основная причина, по которой .NET Core был создан в первую очередь: .NET Framework поставляется с Windows и является глобальнымвещь.Все приложения всегда будут использовать одну и ту же версию фреймворка.Поэтому всякий раз, когда Microsoft выпускает обновление для .NET Framework, они должны быть невероятно осторожными, чтобы не сломать приложения.И это невероятно сложно, потому что бесчисленные приложения зависят от всех вещей в структуре.Даже исправление, возможно, очевидной ошибки может привести к поломке.

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

Таким образом, вы должны принять это и начать разрабатывать свои приложения самостоятельно.Если у вас есть общие зависимости, рассмотрите возможность создания (частных) пакетов NuGet для них, чтобы приложения могли зависеть от них и чтобы у вас был хороший способ их правильно обновить.