Существует ли максимальное количество сборок для приложения .NET?

Question

Несколько приложений поддерживают плагины.

Есть ли недостатки в наличии большого количества плагинов? Есть ли сладкое пятно, за пределами которого возможно снижение производительности?

Какое наибольшее количество сборок, которое вы видели, загружено в приложение?

Answer 1

Однажды я работал над бэкэнд-каркасом, который имел дерево зависимостей сборки более 2500 конечных точек. Это было отвратительно и заняло два часа.

Так что, пока вы можете загружать их тоннами и тоннами, будьте готовы, чтобы люди указывали на вас и бросали вещи.

Answer 2

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

Из-за различных проверок согласованности, которые CLR выполняет при загрузке сборок (например, проверка строгого имени), и вероятности того, что потребуется перебазирование , весьма вероятно, что большое количество сборок может иметь значительную производительность последствия.

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

Три вещи, которые вы могли бы сделать, чтобы улучшить время загрузки, если они стали проблемой:

• Строго назовите ваши сборки и поместите их в GAC во время установки
• Запускать NGEN на сборках со строгим именем GAC во время установки
• Укажите нестандартный базовый адрес для различных библиотек DLL, чтобы минимизировать перебазирование

Для 1 и 2 они в значительной степени идут рука об руку. Прирост производительности NGEN может быть не полностью реализован, если сборки не находятся в GAC из-за строгой проверки имени. CLR может пропустить эту проверку для сборок в GAC.

Вот отличная статья MSDN о времени запуска приложений.

Answer 3

Нет, сладкого места нет. Больше кода занимает больше времени для загрузки и JIT-компиляции. Но это не обязательно предсказуемо, когда это происходит, это происходит по требованию. Максимальный размер ограничен только объемом доступной виртуальной памяти на 32-разрядных компьютерах и размером файла подкачки на компьютерах x64.

Answer 4

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

Сказав это, он субъективен ряду других факторов, таких как «качество» сборок, системные ресурсы и т. Д. И т. Д.

Answer 5

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

Проблемы с номерами сборок чаще всего вызваны слишком большой грануляцией в самом проекте. Я видел монолитное приложение, которое состоит из 100 проектов Visual Studio, потому что архитектор сказал: «нам нужна слабая связь». Попытайтесь придерживаться правила Роя Ошерова: каждая сборка должна иметь физическую (не логическую) причину существования. Логические проблемы лучше решать с помощью пространств имен, а не сборок.

Надеюсь, это поможет.

Answer 6

Одно видимое ограничение - использование памяти. Каждый модуль будет загружен в память. Таким образом, для 32-разрядной ОС вы получаете 1,3 ГБ, а для 64-разрядной ОС ограничение слишком велико, чтобы его можно было использовать в современных приложениях.