Влияние на производительность/память при использовании нескольких сред выполнения .NET в одном решении

Будет ли какое-либо влияние на производительность или потребление памяти, если решение, над которым я работаю (200 проектов csprojects), полностью построено для одной версии .NET CLR (4.5), но широко использует сторонние библиотеки, созданные для более старой версии .NET CLR (2.0/ 1.1) - в моем случае Common.Logging 1.2?

Изучение различных материалов (https://msdn.microsoft.com/en-us/magazine/ee819091.aspx) указывают на то, что, скорее всего, произойдет увеличение потребления памяти из-за Side-by-Side, но неясно, будет ли какое-либо снижение производительности из-за SxS по сравнению с приложением усилий и перестроением всех ссылок. Сторонние библиотеки для той же .NET CLR.

Допустим, мое решение .NET4.5 широко использует common.logging (.NET2.0/1.1). Если я приложу усилия и перестрою (+ при необходимости обновлю исходники) этот файл common.logging в .NET4.5, ускорится ли мое решение (и если да, то достаточно ли этого, чтобы оправдать усилия)?

редактировать (уточнение): решение создает исполняемый файл автономного приложения (без IIS/ASP.NET).


.net c# clr
person Jan Hyka    schedule 29.01.2015    source источник
comment
Слишком сложно оценить влияние предложенной работы. Использование 4.5 вместо 2.0, возможно, может ускорить работу, но многое можно улучшить, изменив старый код с помощью новых/переписанных API-интерфейсов .NET4.5. В заключение я могу сказать, что, вероятно, могу ускорить его   -  person LPs    schedule 29.01.2015
comment
Приложение точки входа определяет используемую среду выполнения. Все остальное будет загружено в этой среде выполнения, если она совместима с версией.   -  person leppie    schedule 29.01.2015
comment
Вы уверены, что на самом деле используете 2 среды выполнения? (обычно этого трудно добиться со строго управляемым кодом, поэтому есть большая вероятность, что вы этого не сделаете)...   -  person Alexei Levenkov    schedule 29.01.2015
comment
Точка входа (исполняемый файл C# .NET) создана для .NET4.5. Увы, он использует старые библиотеки .NET. Насколько я понимаю совместимость среды выполнения .NET, начиная с .NET4.0, она фактически способна загружать столько сред выполнения, сколько необходимо в рамках одного процесса.   -  person Jan Hyka    schedule 29.01.2015
comment
Да, несколько сред выполнения можно запускать параллельно, но не из управляемой точки входа исполняемого файла .net. Он будет использовать унификацию, как описано ниже, и каждая dll, предназначенная для предыдущих версий платформы, будет запускаться в более новой CLR (поэтому dll .net 2.0 запускается в среде 4.5). Запуск параллельных CLR возможен только в том случае, если вы создаете загрузчик на C++ и используете API размещения CLR или аналогичный подход.   -  person Ryan Mann    schedule 29.01.2015

Ответы (2)


arrow_upward
3
arrow_downward

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

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

Ответ: Ваше решение не ускорится за счет перестроения ваших старых проектов в .NET 4.5, поскольку унификация уже выполняет эти сборки в .NET 4.5.

Со связанной страницы.

На следующем рисунке приложение MyApp использует два компонента, Comp A и Comp B. MyApp и Comp A были созданы со средой выполнения версии 1.0, поэтому они содержат статические ссылки на среду выполнения версии 1.0. Компонент Comp B содержит статическую ссылку на сборку .NET Framework, поставляемую со средой выполнения версии 1.1, но из-за унификации перенаправляется для выполнения с использованием сборки .NET Framework, поставляемой со средой выполнения версии 1.0.

Изображение, описывающее унификацию сборки

person sisve    schedule 29.01.2015

arrow_upward
3
arrow_downward

1 процесс не может использовать несколько версий среды CLR с управляемыми исполняемыми файлами, предназначенными для конкретной версии платформы. Вот почему проект, построенный, скажем, на .Net 2.0, не может ссылаться на dll, построенный на .Net 4.5. Однако проект, построенный на 4.5, может ссылаться на dll, построенный на 2.0, потому что среды CLR обратно совместимы друг с другом.

В случае процесса, скажем, приложения Windows Forms, созданного на .Net 4.5, ссылающегося на зависимость .net 2.0, зависимость будет использовать платформу 4.5 Framework, повышая ее.

Теперь, если мы говорим о приложениях IIS, можно было бы иметь два веб-приложения в одном решении, созданном для двух разных версий .net, и оба используют эту версию, но только если каждому веб-приложению предоставляется собственный пул приложений либо через 2 отдельных iis сайты или 1 сайт IIS с двумя отдельными подприложениями, каждое из которых использует отдельный пул приложений.

Пожалуйста, поправьте меня, если я ошибаюсь.

person Ryan Mann    schedule 29.01.2015
comment
Один процесс не может использовать несколько версий CLR, что неверно. Это правильно для управляемых исполняемых файлов (возможно, это то, что вы упоминаете), но это возможно, когда вы пишете свой собственный (собственный) исполняемый файл для размещения нескольких разных версий CLR. - person Christian.K; 29.01.2015
comment
Из-за отсутствия тега c или c++ я бы предположил, что OP не управляет собственным процессом и не использует API-интерфейс CLR. - person Ryan Mann; 29.01.2015
comment
Я согласен. Я просто думаю, что ваше вступительное предложение нуждается в небольшой доработке, оно технически некорректно. Но это ваш выбор формулировки. - person Christian.K; 29.01.2015
comment
Согласно статье, указанной в вопросе, это не совсем так (или, по крайней мере, так я это понял) - цитата. В рамках нашего нового подхода к использованию нескольких сред выполнения в процессе мы отказались от старой, единственной поддерживает API-интерфейсы хостинга и добавил новый набор API-интерфейсов хостинга, призванных помочь вам управлять средой с несколькими средами выполнения. - person Jan Hyka; 29.01.2015