01.02. .Net Development Environment

Поделиться
HTML-код
  • Опубликовано: 7 ноя 2024

Комментарии • 3

  • @KybaLioN66
    @KybaLioN66 2 месяца назад

    thank you very much

  • @KybaLioN66
    @KybaLioN66 2 месяца назад

    Спасибо за видео.
    Как я понял былди которые демонстрированы в видео, при исполнении требует уже установленный заранее виртуальной машины .NET (CLR). Но я знаю что возможно собрать так сказать в standlone project. Где в exe файле будет зашито виртуальная машина. и этот билд можно запускать в любой среде без каких либо зависимостей.
    Можете сказать плюсы и минусы этих подходов ?

    • @mihail_romanov
      @mihail_romanov  2 месяца назад

      Ну я бы тут говорил о 2-х подходах:
      - self-contained сборка (и публикация) проекта. Здесь всё те же IL библиотеки, но (!) в процессе сборки всё, что нужно для запуска приложения: исполнимый файл, runtime и библиотеки .Net, сторонние зависимости, ... - будет собрано в одну папку. И этого будет достаточно для запуска, никаких требований к окружению (ну кроме поддерживаемой версии ОС) не будет.
      Подробнее тут learn.microsoft.com/en-us/dotnet/core/deploying/#publish-self-contained - там же указаны плюсы и минусы подхода.
      Самое главное из плюсов - доступны любые библиотеки и возможности .Net
      - Native AOT (ahead-of-time). А вот тут происходит компиляция сразу в исполнимый код, и да, собирается всё в общий исполнимый файл.
      Опять же подробнее можно почитать тут learn.microsoft.com/en-us/dotnet/core/deploying/native-aot
      Основные сложности, как по мне, это некоторый функционал (например, часть Reflection) не доступен, а значит и те библиотеки, что от него зависят - не доступны тоже.
      Например тут learn.microsoft.com/en-us/aspnet/core/fundamentals/native-aot?view=aspnetcore-8.0#aspnet-core-and-native-aot-compatibility указан функционал ASP.Net Core, совместимый и несовместимый с AOT.
      К сожалению, у меня пока не было поводу поработать с AOT, поэтому какого-то своего мнения у меня пока тоже нет.
      Как по мне, для классических серверных приложений это не особо актуально (разве что для быстрого запуска serverless функций - но в моей текущей практике этого не требуется), а вот ограничения по функционалу - очень существенны.