company_banner

ААА! Пришло время переписывать на .NET Coreǃ

    Все мы давно хотим перелезть на .NET Core, но постоянно что-то мешает. Например, ничего не поделаешь, когда не хватает важных API. В версии 2.0 процесс упростили благодаря .NET Standard 2.0, но это ещё не всё. Ну что ж, Microsoft-боги вняли нашим молитвам и завезли 20 000 API, доступных в виде одного-единственного пакета в NuGet!



    Кому это вообще нужно?


    Вкратце, это нужно всем. Имхо, сама возможность перетащить свои тонны легаси на .NET Core — уже достаточное оправдание для любых жертв.


    Скептикам же надо как бы напомнить, что .NET Core пилится специально для масштабируемых веб-приложений на всех разумных операционных системах (GNU/Linux, macOS и Windows), а более точно выбрать между Core и Framework поможет специальный документ.


    Как это использовать?


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


    Предположим, вы накодили приложуху на ASP.NET MVC для Windows-локалхоста, и вас за это не уволили. Настало время перетащить ее на правоверный Linux, работающий на Azure! Лучше есть слона по кусочкам, а именно:


    • Перетащить всё на ASP.NET Core (но целевой платформой продолжать держать .NET Framework);
    • Переползти на .NET Core (но продолжать юзать Windows);
    • Перепрыгнуть на GNU/Linux;
    • Запуститься на Azure.

    Понятно, что к этому великому плану стоит подходить не как к строительству коммунизма, а разумно. Например, если нужно показать биг боссам запуск на Azure — с этого и стоит начать. Если же думать лень (мне, например, точно лень), наши лидеры написали специальную методичку по обретению веры в .NET Core.


    Вкратце, нужно расчехлить NuGet, поставить пакет Microsoft.Windows.Compatibility и обнаружить, что стала доступна огромная куча разных нужных и ненужных API.


    Важно понимать, что этот самый Microsoft.Windows.Compatibility всё еще яростно допиливается, так что все офигительные истории нам только предстоят.


    Сейчас имеется следующий набор ништяков (таблица получилась огромная; чувак, читающий этот пост с мобилы: прости меня пожалуйста!):


    Компонент Статус Windows-Only
    Microsoft.Win32.Registry Available Yes
    Microsoft.Win32.Registry.AccessControl Available Yes
    System.CodeDom Available
    System.ComponentModel.Composition Coming
    System.Configuration.ConfigurationManager Available
    System.Data.DatasetExtensions Coming
    System.Data.Odbc Coming
    System.Data.SqlClient Available
    System.Diagnostics.EventLog Coming Yes
    System.Diagnostics.PerformanceCounter Coming Yes
    System.DirectoryServices Coming Yes
    System.DirectoryServices.AccountManagement Coming Yes
    System.DirectoryServices.Protocols Coming
    System.Drawing Coming
    System.Drawing.Common Available
    System.IO.FileSystem.AccessControl Available Yes
    System.IO.Packaging Available
    System.IO.Pipes.AccessControl Available Yes
    System.IO.Ports Available Yes
    System.Management Coming Yes
    System.Runtime.Caching Coming
    System.Security.AccessControl Available Yes
    System.Security.Cryptography.Cng Available Yes
    System.Security.Cryptography.Pkcs Available Yes
    System.Security.Cryptography.ProtectedData Available Yes
    System.Security.Cryptography.Xml Available Yes
    System.Security.Permissions Available
    System.Security.Principal.Windows Available Yes
    System.ServiceModel.Duplex Available
    System.ServiceModel.Http Available
    System.ServiceModel.NetTcp Available
    System.ServiceModel.Primitives Available
    System.ServiceModel.Security Available
    System.ServiceModel.Syndication Coming
    System.ServiceProcess.ServiceBase Coming Yes
    System.ServiceProcess.ServiceController Available Yes
    System.Text.Encoding.CodePages Available Yes
    System.Threading.AccessControl Available Yes

    А что делать с Windows-only API?


    Страдать, чо.

    Для танкистов. Не все API одинаково переносимы. Если ты остаешься на Windows, проблем никаких нет. Если же хочешь приобщиться к святости Ричарда Столлмана и Тима Кука на GNU/Linux и macOS соответственно, придется страдать.


    Взглянув на табличку ништяков, видим: Windows-only компонентов там чуть ли не половина. Добрые Microsoft-боги, тем не менее, позволяют успешно компилировать такой код под любой платформой. При попытке использования несуществующей фичи мы наткнемся на PlatformNotSupportedException в рантайме, поэтому все такие фичи нужно будет густо обмазать вызовами RuntimeInformation.IsOSPlatform():


    private static string GetLoggingPath()
    {
        // Verify the code is running on Windows.
        if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
        {
            using (var key = Registry.CurrentUser.OpenSubKey(@"Software\Fabrikam\AssetManagement"))
            {
                if (key?.GetValue("LoggingDirectoryPath") is string configuredPath)
                    return configuredPath;
            }
        }
    
        // This is either not running on Windows or no logging path was configured,
        // so just use the path for non-roaming user-specific data files.
        var appDataPath = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);
        return Path.Combine(appDataPath, "Fabrikam", "AssetManagement", "Logging");
    }

    Как же понять, какая API-шка будет работать только в Windows? Документацию ведь никто не читает, верно?


    Дорогой мой любитель программирования копипастой со StackOverflow! Microsoft — боги суровые, но справедливые, поэтому буквально пару недель назад они запилили API Analyzer tool. С помощью Roslyn эта тула помечает Windows-only API, причем только тогда, когда целью выставлен .NET Core или .NET Standard.



    Что делать с ошибками? Как было сказано ранее, страдать.


    • Удалять непортируемый код. Зачем нужна фича, если она не запускается на macOS? :-)
    • Усердно рефакторить код с помощью других, более кроссплатформенных API. Благо это обновление принесло таких во множестве.
    • Расставить проверки на тип операционки в тех местах, где происходят GNU/Linux-специфичные вещи, которые просто не нужны в Windows.

    В примере с картинки кто-то пытается вычитать настроечку в Реестре. Можно обернуть эту строчку в проверку, выполнять ее только на Windows. В GNU/Linux эквивалент этой строчки будет другим, куда более мучительным.


    Заметьте, что Windows Compatibility Pack — это метапакет. В Microsoft отлично понимали, что обычные люди не будут мучиться с выискиванием отдельных мелких пакетиков и захотят перейти на новую платформу одним прыжком (с учетом оговорок выше). Тем не менее, если ты — вдумчивый крутой разработчик, то можно притаскивать фичи и поодиночке. Таким образом, можно будет выкинуть куда больше зависимостей на ненужный хлам.


    Что дальше?


    Морально готовишься к портированию. Устанавливаешь Windows Compatibility Pack. Изучаешь ништяки, коих там более 20 тысяч, включая EventLog, WMI, Performance Counters, Windows Services итп.


    Если хочешь сделать приложуху кроссплатформенной — запускаешь API Analyzer. Можно предварительно немного поплакать или тяпнуть водочки.


    К сожалению, сейчас .NET Core не покрывает нужды десктопной разработки. Возможно, когда-нибудь это изменится. Но это уже совсем другая история.


    Если же хочется больше узнать о .NET вообще и .NET Core в частности, ждем тебя на DotNext 2018 Piter, которая пройдет, внезапно, в Питере. Очень советую к этой конфе уже попробовать что-нибудь запилить или портировать на Core, чтобы накопился пул вопросов к спикерам.

    JUG Ru Group
    617,28
    Конференции для программистов и сочувствующих. 18+
    Поделиться публикацией

    Комментарии 68

      +3
      Про десктоп, проект AvaloniaUI. Базируется на XAML. Ну ещё и не релиз пока, но можно уже много интересного делать.
        0
        О, расскажи про Авалонию. Ты уже что-нибудь пробовал сделать? Что показалось наиболе интересным, чудесным и вообще труЪшным? Какие грабли собрал?
          +1
          ARG89 указал кого надог звать, ну я оставлю замечательную презентацию с прошлого dotnext отkekekeks
            +1
            Ну до WPF пока не дотягивает. Но слова были, что остаётся только мечтать о десктопе на net.core, но уже есть проект, на котором уже можно делать вещи. И это радует.
              –8
              О, интересно читать комментарии официального представителя, который отвечает как быдло последнее.
                +3
                Чего? Короче, даже знать не хочу, где я тебе ответил как быдло. Просто пойми, я из Новосиба, с Богдашки, мы с Васей-Молотом ещё в школе столько конкурентов по .NET-аутсорсу в тайге закопали, а тогда и .NET ещё не было. Накладывает отпечаток на стиль изложения.
              +1
              Зовите kekekeks, он расскажет)
                +4

                А что рассказывать, на дотнексте я уже по этому поводу вещал. Ждите релиза беты в начале года.

                  +1
                  А датагрид в бете будет?
                    +3

                    Нет. У вас всё ещё сохраняется уникальный шанс стать тем самым человеком, который перепишет все 50К+ строк кода опенсорсного грида из состава сильверлайта. Или 125К строк кода Xceed-овского грида.

                      0
                      а есть какие либо, хотя бы приблизительные сроки, когда планируется реализовать датагрид?
              +3
              Мы перепрыгнули уже довольно давно, полет нормальный. Кластер из нескольких Коровских нод на Никсах за Хапрокси и последовательный деплой без даунтайма — берем лучшее из обоих миров.
                +1
                Можете немного подробнее рассказать как все работает? Хотим у себя сделать нечто подобное, но пока только в начале пути. Например, чем деплой делаете?
                  0
                  Ansible. Но это не принципиально. Можно шелл-скриптом из репозитория раскатывать, если нод немного. Деплой в новую папку, стоп старой, старт новой версии. Откат еще быстрее. Если ХА не нужен, можно оставить Кастрюлю, смотрящей в сеть, как есть. Делали нагрузочные на Никсах, она параллельно летает. Асинк-авейт, все такое. Нгинкс как прокси перед Кастрюлей показался избыточным. Но то дело вкуса.
                +2
                Непонятно. System.Data.SqlClient доступен был с незапамятных времен, отдельным пакетом. Если Microsoft.Windows.Compatibility можно ставить по частям, то так и надо написать.
                  0
                  Да, можно ставить по частям.
                  +4
                  Не только «десктопные приложения» неподдерживаются…
                  System.Diagnostics.PerformanceCounter и System.DirectoryServices только только стали доступны как preview1 (в вашей таблице Coming это и означает). т.е. портировать серверный код (где без данных библиотек не обходится) — удел одиночек. Писать новые проекты — конечно надо под core, осваивая новую МС телеметрию и вынося адапетр к ActiveDirectory в отдельный удаленный сервис, который будет крутится под Classic .NET Framework.
                    0
                    Ну тут такое, release early, release often, как говорил батюшка наш Эрик Реймонд. Наверное, раз уж подписался на участие опенсорце, придется жить по опенсорцным заповедям: постоянно сидеть на превьюхах, мониторить новости, адоптить частые апдейты. И главное, справляться своими силами, а не ждать, пока добрый дяденька из Microsoft тебе всё запилит.
                      +5
                      Да, наверное есть о чем поговорить друг с другом любителям посидеть на превьюхах ядра линукса.
                    +3
                    К сожалению, сейчас .NET Core не покрывает нужды десктопной разработки. Возможно, когда-нибудь это изменится. Но это уже совсем другая история.

                    .NET Core, как и старший .NET Framework, умеет в DllImport, маршалинг между managed и unmanaged. Т.е. платформа как исполнитель управляемого кода и интегратор с неуправляемым ОС-специфичным кодом как раз все позволяет и покрывает. Поэтому правильнее говорить, что нынешний набор пакетов не покрывает все нужды десктопной разработки.
                      +3
                      Всё равно осадочек остался от того что протащили windows-only API. Лучше совсем без них, и для windows-a предоставлять их в виде отдельных nuget пакетов. В принципе это ещё не поздно исправить, но никто этим заниматься не будет. Сейчас у них цель, проапгредить и заоптимизировать сетевой стек.
                        0
                        Так ведь они же и так отдельными пакетами идут?
                          0
                          Идея в том, что бы не было их как таковых в стандарте, и не думать о том, что гдето можно схлопопать платформо зависимое исключение.
                            0
                            не подключай и думать не придется:-)
                        –1
                        Настало время перетащить ее на правоверный Linux, работающий на Azure!

                        Один я вижу в этих словах противоречие? =)
                          +1
                          Всё чисто! :-)
                            0
                            А в чем противоречие то?
                              +1
                              Только вы один, да)
                              +5
                              А зачем мы давно хотим перелезть на .NET Core?
                                +2
                                Тот же вопрос. Вот есть у меня зоопарк (теперь типа legacy) приложений на .NET 4.Х. Худо-бедно работает и мы трудимся над расширением функционала.
                                Тут вышел .NET Core, и мы должны переписывать? Чего ради? Для повышения производительности? Для большей переносимости?
                                Не уверен, т.к. в моей компании это не принесет денег. А устранение косяков и расширение функционала — принесет.
                                  0
                                  Стильно, модно, молодежно :)
                                    0

                                    Есть клиенты, которые не хотят сервера на Windows, но им подходит некое ПО на ASP.NET.
                                    Переводим ПО на .NET Core, добиваемся устойчивой работы в Linux, продаём, profit.

                                      0
                                      Ясно.
                                      Они просто не умеют их поддерживать — просто продайте им ещё и саппорт для Windows серверов :)
                                      profit x 2
                                        0

                                        Дело не в этом. Есть такое слово "импортозамещение". И оно уже давно является драйвером изменений в IT, причем не только в госсекторе.

                                          +1
                                          А у вас СУБД «правильная»?
                                          И только не говорите заказчику, что вы используете технологии Microsoft.
                                          В «не только в госсекторе» мне кажется импортозамещение началось уже сразу с появлением этого «не только в госсекторе» :)
                                            +1

                                            По СУБД тоже есть хорошие новости:
                                            https://www.microsoft.com/ru-ru/sql-server/sql-server-2017

                                              –1
                                              Я не о том, вы бы ещё клиентам предложили Windows Server в виртуализации Linux запустить, если они сервера на Windows не хотят. Вы им тогда и лицензии на vmware продадите, и саппорт виртуализации, и саппорт на Windows сервер в виртуализации… уже я даже сбился со счёт на сколько надо profit множать в таком случае.
                                              Это всю шутки конечно, но с долей правды.

                                              И всё же «масло масляное» — от Microsoft вы так заказчиков не сбережете, «они» всёравно будут руководить вами :)

                                              Microsoft всегда имел хороший маркетинг для программистов и это вот «ВСЁ» с open source и linux на фоне прошлых «неудачных» и выгодных для Microsoft технологий, должно насторожить тревожного разработчика.
                                              0
                                              Можно просто посчитать на сколько денег продали астралинукса и других отечественных линуксов за последний год для гос и около контор. И их реально сейчас пытаются активно внедрять. Возникла потребность в ПО для линуксов. У многих уже были свои работающие решения на dotnet на винде, кто-то решил заказать замену своим еще dos программам. Выход dotnet core 2 сильно помог компаниям, не меняя программистов и не переписывая весь код, постараться вписаться в этот праздник импортозамещения.

                                              По базам: postgresql там из коробки даже в special edition (хотя не самый новый), кому не нравится, есть postgrespro с плюшками и сертификатом. Работает с EntityFramework.

                                              Требования на разработку включают исходники на все ПО с совместимой лицензией, авторское свидетельство. А откуда технологии — дело не первой важности. Можно подумать ядро линукса разрабатывается у нас.

                                              Еще из примеров: не так давно описывали на хабре свой случай с видеорекламой 2ГИС. Так что это востребовано.
                                      +3
                                      Надо было сразу на PHP, Java или Go писать что бы потом не ползать по .net core-ам.
                                      Да и зачем всё переписывать если есть виртуальные машины с образами систем готовых систем, которые разворачиваются по мере необходимости. И так работает зачем еще переплачивать?
                                        0
                                        И так работает зачем еще переплачивать?

                                        Как я понял, в статье речь о том, что это стало практически бесплатно. Без виртуальных машин и прочего инструментального оверинжиниринга.
                                          0
                                          Посмотрите на современный софт, оверинжиниринг никого не пугает. Да же наоборот, притягивает. Контейнеры, виртуальные машины, облака. Зачем переписывать побольше инстансов оплатил и вперёд. Труд программистов дорог, а вычислительных мощностей хоть ж… ой ещь и не дорого.
                                            0
                                            В современности много бестолковых специалистов, которые готовы технологиями (и ресурсами для них) покрывать свою безграмотность. Безусловно, их такие возможности радуют.
                                            Виртуализация — отличная вещь там, где она нужна. В любую дырку толкать докер лишь потому, что это мейнстримово — это очевидная глупость, за которую платит бизнес.

                                            Зачем переписывать
                                            Не нужно ничего переписывать, о том и статья.
                                              0
                                              Странно, а в заголовке «переписывать».
                                              И по факту, чтобы приложение было .NET, а стало Core — его придётся переписывать. Да, какую-то часть кодовой базы можно использовать повторно.
                                                +1
                                                Странно, а в заголовке «переписывать».
                                                Забавно, но в тексте статьи этого нет. Все эпитеты про «перетащить» подразумевают запуск в новом окружении. Пакет призван обеспечить слой совместимости на уровне исходников.

                                                И по факту, чтобы приложение было .NET, а стало Core — его придётся переписывать.
                                                Это совсем не факт, ибо сильно зависит от самого приложения и состояния сабжект-пакета.
                                                +2
                                                Если кто-то питает иллюзии, что ничего не придется переписывать — стоит перестать это делать.
                                                Из того, на что напарывались:
                                                — Nhibernate -> Dapper
                                                — Ninject -> стандартный DI
                                                — log4net заводится через одно место
                                                — полностью новая инициализация сервиса(на Net 4.6 был OWIN + Topshelf)
                                                — завести NUnit на TeamCity нифига не просто и тащит за собой обновление TeamCity
                                                — переписать билд-скрипты на dotnet build|publish
                                                  0
                                                  Почти все что вы перечислили можно описать одним словом: сторонние библиотеки/продукты.

                                                  Да, если сторонний продукт который вы используете не поддерживает Core — вы не сможете без переписывания работающего с ним кода переехать на Core. Это очевидно же…

                                                  PS так вернули же msbuild в core, разве нет?
                                                    0
                                                    Ninject -> стандартный DI
                                                    Актуальный (стабильный) Ninject умеет в .NET Standard 2.0
                                                      0
                                                      — Nhibernate -> Dapper
                                                      — Ninject -> стандартный DI
                                                      — log4net заводится через одно место
                                                      — полностью новая инициализация сервиса(на Net 4.6 был OWIN + Topshelf)
                                                      — завести NUnit на TeamCity нифига не просто и тащит за собой обновление TeamCity
                                                      — переписать билд-скрипты на dotnet build|publish

                                                      1. Nhibernate имеет единственную зависимость Iesi.Collections, которые уже перетащены на кор.
                                                      2. Поддерживает кор
                                                      3. Но заводится же. При этом это код, который пишется единожды. Плюс сам выбор инструмента тоже влияет, у нас например используется ELK и мы ничего не переписывали.
                                                      4. Тут да, надо переписать, но нужно понимать, что Topshelf зависит от Windows service инфраструктуры, которой непонятно откуда взяться на кроссплатформенном окружении. Хотя в 2.1 вроде должны каким-то образом исхитриться. Видимо так же, как эмуляция реестра файлами на линуксе, которую они делали.
                                                      5. Обновление TeamCity тоже делается единожды, причем практически без затрат.
                                                      6. 30 минут работы девопса.

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

                                                      Плюсов для меня лично больше. Самый большой — возможность переключатся между ветками в гите без перезагрузки всего солюшена + удобство в потреблении и создании нугет пакетов.

                                                      А вот опыт товарища focuspocus показателен, там мне нечего сказать, кроме как «сочувствую» :)
                                                        0
                                                        Для нас плюсов тоже было больше, чем минусов — иначе бы не переводили.
                                                        Пост был не про то, что нельзя перехать, а про то, что даже на средних размеров проекте это вполне себе ощутимые трудозатраты(ну или мы что-то не так делали). Данный момент, как минимум, стоит держать в голове.
                                                        Также раз уж написал про проблемы, то напишу и про маленькие приятности, помимо кросплатформенности, которые дает net core:
                                                        — удобный механизм переопределения appsettings.json(в прошлом app.config) из коробки: можно таскать переопределения ключей из консоли, файлов, перменных окружения
                                                        — csproj файлы стали намного более читаемые и удобные. теперь на них можно смотреть(и мерджить) без боли
                                                        — более удобное подключение нугет пакетов: ссылка на пакет добавляется в csproj и все. без всяких там UI и сгенерированных hintPath, как это было в старом csproj.
                                                        — стандратный DI вполне адекватен и вообщем-то что-то стороннее ставить не всегда есть смысл
                                              +2
                                              Может быть стоит наиболее общие части кода выносить в рамки .Net Standart?
                                                +1

                                                .NET Standard не содержит кода, это просто перечень API. Код находится в фреймворках (.NET 4.6 или .NET Core 2.0, например). Фреймворки реализуют ту или иную версию стандарта.

                                                +1

                                                Стоит упомянуть, что из проектов на .NET Core 2.0+ можно референсить сборки и нугеты ЛЮБОЙ версии .NET, и оно будет работать под линух, если либа не использует windows-specific API.


                                                То есть если вы — автор библиотеки, то не обязательно переезжать на кору, достаточно проверить, что нет windows-specific вызовов, или обернуть их в if-else.


                                                Мы так поступили в Apache Ignite.NET. Всё работает под линух и макось, но сохранена поддержка VS 2010.

                                                  +2
                                                  К чему Microsoft идет в итоге?

                                                  Делает Кросс-платформенный фреймворк + отдельно фреймворк для винды. Или все же сделает один адекватный фреймворк подо все + отдельный пакет для лучшей интеграции с виндой?
                                                    +2
                                                    Сделать кросс платформенный NET Core это реально хорошая идея и в какой-то степени может потеснить Java на nix платформе.
                                                      +1
                                                      1) Сделать полную поддержку на Linux — тогда Java подвинется, так как зачастую именно цена хостинга + лицензий (отпугивает стартапы) + отсутствие тулзов линукса отпугивает крупные проекты.

                                                      2) Сделать Gui-инструмент для Linux/MAC — тогда уже подвинутся все остальные.
                                                        +2
                                                        Радуюсь появлению .net core, все свои пет проекты пишу на нем, под VS 2017 и Win10, а запускаю их на simplecloud на 150р тарифе под Ubuntu.
                                                        Мне как раз подходит на 100%.
                                                          0
                                                          1) Сделать полную поддержку на Linux — тогда Java подвинется, так как зачастую именно цена хостинга + лицензий (отпугивает стартапы) + отсутствие тулзов линукса отпугивает крупные проекты.

                                                          Так или иначе движ есть. MS раньше позиционировалась как вещь в себе, типа нафиг эти ваши линуксы, у нас есть все(сервер, базы, серверные приложения) и мы крутые. Но мир поменялся, линукс плотно осел на сервер сайде и MS долю серверного рынка на Linux полностью потеряла. Потом они начали пытаться «запрыгнуть в уходящий вагон» и начали накручивать всякую совместимость(она правда и до этого была, но кто ей пользовался хз) с Linux, en.wikipedia.org/wiki/Windows_Subsystem_for_Linux.
                                                          Про последнее я тоже не думаю что это прям взлетит. Общие кейсы в голову не приходят, а какие-то узкоспециализированные интереса не представляют.
                                                          А вот .NET это несколько другое общий и обширный вариант использования это ASP.NET да и да и просто серверные .NET приложения. И вот с этим крюком MS может залезть в Linux вагон.

                                                          Это не говорит о том, что все ринутся переписывать. Но при выборе платформы для нового приложения решение может склониться в сторону .NET on Linux
                                                      +4
                                                      я извиняюсь, но имело смысл указать, что это перевод поста Иммо — blogs.msdn.microsoft.com/dotnet/2017/11/16/announcing-the-windows-compatibility-pack-for-net-core
                                                        +1
                                                        Ссылка же на оригинал новости есть прямо в первом абзаце (и она была там всегда, до этого комментария).

                                                        Но это не перевод, а рерайт. Несмотря на в общем похожую структуру, есть важная разница в ряде моментов: например, я утверждаю что на .Net Core переходить нужно в любом случае просто потому что это Free Software, и мне как FS/OSS-человеку это самое важное. Я супер редко пользуюсь какими-либо продуктами Microsoft именно потому, что это не Free Software, неважно насколько качественными или полезными они при этом являются. Но это совершенно не годится на официальную позицию Microsoft.

                                                        На «официальную позицию» не годится так же идея о том, что текущий подход к портированию — неудобный, и людям которые хотят что-то портировать — им остается только страдать. На официальную позицию не тянет троекратное упоминания подозрения, что половина читающих эту статью — те еще быдлокодеры и копипастеры со StackOverflow.

                                                        В принципе, мне ставить галочку «перевод» даже выгодно. Но вряд ли Microsoft обрадывалось бы двачерским словечкам и оборотам, которые приписали бы им словом «перевод» в заголовке. Это важный для меня момент, т.к. я не собираюсь ни отказываться от двачерской лексики, ни от глумёжа и обвинений в быдлокодерстве, итп — это мой стиль. Но при этом не хочу иметь официальные конфликты с Microsoft.

                                                        Я думаю, так или иначе, большинство новостей в мире фреймворков вторичны, и новости будут так или иначе идти от корневых источников — мейлинг-листов и сайтов авторов. Так что в дальнейшем рерайты новостей я писать продолжу. Вряд ли стоит выражать вторичность новости в виде галки «перевод».

                                                        Какие выводы я сделал из вашего комментария: в будущем нужно будет делать более глубокую проработку новости и менять её структуру, чтобы она не была «переводом» на уровне структурных блоков (или хотя бы — порядка структурных блоков).
                                                        0
                                                        Переезжать серверным системам стоит если:
                                                        а) вы видите профит от снижения затрат на хостинг за счет перехода на линукс
                                                        б) у вас (микро)сервисы и вы понимаете зачем вам докер
                                                        в) ваш заказчик купил линукс сервера, не посоветовашись с вами

                                                        Новые проекты имхо стоит все-таки начинать сразу под netstandard2.0 или вообще на java от греха подальше=)
                                                          +5
                                                          Был angularjs/webapi2/signalr + workerservice проект с EF 6 на postgresql, который надо было перетянуть под linux.
                                                          Из граблей в основном грабли от ms, сторонние либы на удивление быстро и без особого изменения поведения/конфигурации перескочили (autofac, automapper, hangfire, npgsql и тд):
                                                          1) EF 6 -> EF Core 2.0: нет groupby (уже в гите); нет lazy loading(больше года делают и в лучшем случае в начале 2018); с хранимками и маппингом функций бывают траблы; многие ко многим только через промежуточную сущность(но обещают сделать как и былО).
                                                          2) Ldap: Не из коробки. два года обсуждали, сделали пока только под винду github.com/dotnet/corefx/issues/2089, но есть различные форки новеловской либы.
                                                          3) WebApi 2 -> aspnet core 2: Были забавные случаи с байндингом, где не стоял явный [FromBody]: приходили объекты с пустыми полями, документация по переезду про это мало знает, люди мутят гибридные байндеры. Пришлось подразбираться с конфигурацией приложения при запуске, с конфигурацией (ConfigurationManager появился только с этим пакетом), контейнеров, воткнуться в пайп(чтобы ловить исключения).
                                                          4) Signalr: относительно недавно появился preview. Немного доделок и все заработало.
                                                          5) Были грабли с определением рабочего каталога при запуске с отладкой и без (фикс только сегодня за пулреквестили)
                                                          6) решарпер со студией пару раз зареференсили либу вместо nuget пакета, нужно следить.
                                                          7) отказались от tika.net потому, что автор ikvm.net забил весной на проект и переезда не будет.

                                                          Итого: самая большая боль — EF Core
                                                            0
                                                            Вопрос в сторону, поделитесь опытом, а почему вы предпочли оставить autofac когда в Core DI из коробки (который я не использую, правда я ни один стандартный IoC container не использую поскольку мне нужна поддержка экземпляров «per session» и решается это как раз отказом от IoC container'ов и ручным DI)?
                                                              0
                                                              В освновном из-за конфигурации и некоторых возможностей, а также лимита времени(и немного лени). Конфигурация DI переехала вообще без изменений. В проекте не использовался скан сборок с автоматической конфигурацией. Был сайт, фоновый сервис и несколько сервисных утилит. В каждой программе свой набор компонент и свой конфиг.
                                                              У нас часто используется Lazy<>, чтобы вещи, которые не всегда используются в сервисе, не создавались каждый раз. Насколько я помню, в дефолтном контейнере забраковали open generics. К тому же есть пара мест с child контейнерами (этой фичи тоже нет стандартном). Еще было бы лениво заменять в конструкторах ILogger на ILogger, у нас уже был модуль для autofac, который делал черную магию, зная о типе, куда будет инжектироваться параметр.
                                                            0
                                                            Ну, lazy loading больше для прототипов же фича, в нагруженном же проекте lazy loading является лучшим способом убиения производительности…
                                                              0
                                                              У нас не настолько нагруженный проект был, и его нужно было мигрировать. Да и я б еще подумал брать ли вообще EF в нагруженный проект. Суть не в том, что у нас ленивые жопки, не знающие про n+1, а в том, что это удобнее, чем делать отдельно .Load(), и лучше eager loading данных, которые могут не понадобиться. Кто-то этим пользуется, кто-то нет. Заменить один случай lazy loading — не проблема вообще, но миграция проекта — это довольно кропотливая работа, нужно было пересмотреть много мест по коду.
                                                              Фича Lazy loading — холиварная тема. Вот там тонны добра с обеих сторон, отметились даже некоторые известные люди github.com/aspnet/EntityFrameworkCore/issues/3797
                                                                0
                                                                Lazy loading плохо выглядит архитектурно: заполненность свойства оказывается зависима от того, был ли освобожден контекст и было ли ранее чтение из этого свойства пока не был освобожден контекст. Куча неявного состояния. Как результат — полагающийся на LL код получается хрупким и может перестать работать из-за изменений в совершенно другом куске кода.

                                                                Если уж действительно важно загружать данные по требованию — лучше использовать Explicit loading, передавая контекст вместе с сущностью. Необходимость передачи контекста в метод исключает ситуацию когда контекст освободили а потом пытаемся сделать запрос.
                                                                  0
                                                                  Выход: не прокидывать сущности наружу.
                                                                  У нас слой сервисов (не путать с веб-сервисами) никаких сущностей даже между собой(сервис-сервис) не передает, не говоря уже о выкидывании наружу — только маппинг во входные/выходные типы, либо передача идентификаторов. Как правило, контекст базы инжектируется общий на скоуп, поэтому проблем здесь нет.

                                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                          Самое читаемое