.NET Core и IIS - PullRequest
       10

.NET Core и IIS

0 голосов
/ 23 октября 2018

В настоящее время у нас есть платформа .NET 4 для веб-API, которая размещается в IIS с использованием пула приложений, использующего .NET 4 CLR.

Мы изучаем миграцию веб-API с .NET 4 на.NET Core 2.1 (для улучшения производительности).Веб-API имеет другие ссылки на DLL, которые были созданы с использованием .NET 4 Framework.У меня есть простое доказательство того, что концепция работает и работает с использованием .NET Core 2.1, и ссылки, созданные с использованием платформы .NET 4, импортируются нормально, так как я могу ссылаться на них, и проект собирается.

Если яиметь новый веб-API .NET Core 2.1, ссылающийся на сторонние библиотеки DLL с использованием .NET Framework 4, который затем будет размещен в IIS с использованием CLR 4 ... как мы увидим увеличение производительности?Если все выполняется с использованием CLR 4, не является ли это узким местом для производительности?Или это двоичные файлы, которые CLR считывает более производительными, где вы увидите лучшую производительность?

Буду очень признателен за любые указания, так как сейчас я очень смущен!

Спасибо

1 Ответ

0 голосов
/ 24 октября 2018

Это зависит от того, как вы справляетесь с вещами..NET Core 2.0+ полностью поддерживает .NET Standard 2.0, который имеет достаточно большой API-интерфейс, чтобы охватить большинство функций .NET Framework.В результате компилятор позволит вам добавить ссылку на библиотеку .NET Framework на проект, который фактически нацелен на .NET Core 2.0+.Нет никакой гарантии, что библиотека будет на самом деле работать (и вы получите предупреждение об этом), но если она не использует специфичные для Windows API, есть очень хороший шанс, что она будет работать нормально.

Если предположить, что это так с вашими библиотеками .NET Framework, и вы нацелены на что-то вроде .NET Core 2.1, то вы на самом деле не используете .NET Framework, и вам даже не нужно.NET Framework установлен на сервере, на котором вы развертываете.Все необходимые зависимости фреймворка будут получены из среды выполнения .NET Core или даже могут быть упакованы вместе с вашим приложением, если вы выберете автономное развертывание.В этом случае после компиляции практически несущественно, что библиотеки, на которые вы ссылались, действительно нацелены на .NET Framework.

Если, однако, библиотеки не работают без полноценного .NET Framework, вы все равно можете создать приложение .NET Core,но вы будете вынуждены продолжать ориентироваться на .NET Framework, а не на .NET Core.В этом случае вы, конечно, будете зависеть от .NET Framework CLR, что влечет за собой снижение производительности.Тем не менее, приложение ASP.NET Core, например, по-прежнему в целом более производительно, чем что-то вроде приложения ASP.NET MVC, поэтому вы получите некоторые выгоды - просто не так много, как если бы вы нацеливались на .NET Core.

Независимо от конечной цели, ваше приложение на самом деле обслуживается через Kestrel.IIS действует просто как обратный прокси.

...