Блог

Мы планируем перенести устаревшее приложение, использующее корпоративную библиотеку 4.1, которая использует .Net 3.5 в веб-приложении .Net 4.0.

Нам интересно, вызовет ли это какие-либо проблемы с производительностью? Будет ли код .net 3.5 выполняться в другом пуле приложений?

Я, наконец, нашел ответ на это. Проблема с производительностью, о которой я ранее упоминал, обнаруженная моей командой, вызвана чем-то другим. Не загружается .NET 3.5 в домене приложения .NET 4.0.

Читая эту статью:http://msdn.microsoft.com/en-us/magazine/ee819091.aspx

Встроенный SxS не решает проблемы совместимости, с которыми сталкиваются разработчики библиотек. Любые библиотеки, загружаемые приложением напрямую — либо через прямую ссылку, либо через сборку.Load — продолжит загружаться непосредственно в среду выполнения и AppDomain загружающего ее приложения. Это означает, что если приложение перекомпилировано для запуска во время выполнения .NET Framework 4 и все еще имеет зависимые сборки, созданные на основе .NET 2.0, эти зависимости будут загружаться на .Среда выполнения NET 4 также. Поэтому мы по-прежнему рекомендуем протестировать ваши библиотеки на всех версиях фреймворка, который вы хотите поддерживать. Это одна из причин, по которой мы продолжаем поддерживать наш высокий уровень обратной совместимости.

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

4.0 является надмножеством 3.5, поэтому проблем возникнуть не должно. Весь ваш код 3.5 будет работать так же, как при сборке с VS 2008. Сначала вам нужно следовать этому,
Есть ссылка на MSDN Что нового в
руководстве по миграции .NET Framework 4 на .NET Framework 4
Пошаговое руководство по совместимости приложений с .NET Framework 4 RTM

Если вы выполните поиск в Google, вы найдете множество статей, озаглавленных что-то вроде «Что нового в 2010». Вы не найдете таких вещей, как «Что изменилось»

За исключением этого небольшого лакомого кусочка из MSDN:

.NET Framework 4 полностью совместим с приложениями, созданными с использованием более ранних версий .NET Framework, за исключением некоторых изменений, которые были внесены для повышения безопасности, соответствия стандартам, корректности, надежности и производительности.

.NET Framework 4 автоматически не использует свою версию среды выполнения common language runtime для запуска приложений, созданных с использованием более ранних версий .NET Framework. Для запуска старых приложений с .NET Framework 4 необходимо скомпилировать ваше приложение с целевой версией .NET Framework, указанной в свойствах вашего проекта в Visual Studio, или вы можете указать поддерживаемую среду выполнения с помощью элемента в файле конфигурации приложения.

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

Хотя Microsoft многое сделала для сохранения обратной совместимости с предыдущей версией среды выполнения, вы должны знать, что есть несколько критических изменений. Вы найдете их документированными в MSDN здесь:

Проблемы с миграцией .NET Framework 4 (включая документацию по ASP.NET, .NET Core, Data / ADO.NET, WCF, WPF и XML)

Корпорация Майкрософт также предоставляет рекомендации и ссылки на дальнейшие задачи планирования миграции:

Руководство по миграции на .NET Framework 4

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

Планируйте провести собственное тестирование производительности. Для получения рекомендаций смотрите это из шаблонов и практик.

Я не знаю, какие блоки вы используете, но вам следует рассмотреть возможность перехода на EntLib версии 5.0, поскольку в блоке приложения logging были значительно улучшены характеристики, а также проведен рефакторинг / очистка базовой инфраструктуры. Ознакомьтесь с Руководством по миграции для Enterprise Library 5.0.

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

Библиотеки DLL .NET 3.5 загружены в отдельный домен приложения, чем .NET 4. Таким образом, все вызовы библиотек DLL .NET 3.5 из .NET 4 будут выполняться в домене приложения. Это означает довольно большие накладные расходы. Если вы не можете перестроить исходный код 3.5 в .net 4, я бы не рекомендовал его использовать. Один из моей команды попробовал это, а затем они увидели довольно низкую производительность, поэтому вернулись к .NET 3.5. Пока мы не получим исходный код для всех библиотек .net 3.5 или пока поставщики не выпустят библиотеки .net 4 DLL, мы не собираемся обновлять нашу кодовую базу до net 4.