Как живётся? Не жалеете? Часто ли ломаются билды? Часто ли натыкаетесь на баги? Хватает ли библиотек? Хватает ли тулинга? Как в поддержке и сопровождении?
Что хорошего дал вам .NET Core?
HgLab: Mercurial Server and Repository Management for Windows
Re: Хипстеры, отзовитесь! А вот у кого.NET Core в продакшене?
Н>Как живётся? Не жалеете? Часто ли ломаются билды? Часто ли натыкаетесь на баги? Хватает ли библиотек? Хватает ли тулинга? Как в поддержке и Вот у этих ребят поспрашитвай: сопровождении?
Вот у этих ребят поспрашивай: http://sk.ru/net/1120859/ http://www.adeptik.com/
Недавно с Морозовым разговаривал.
Я так понял, что они уже в это дело въезжают.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re: Хипстеры, отзовитесь! А вот у кого.NET Core в продакшене?
Здравствуйте, Нахлобуч, Вы писали:
Н>Как живётся? Не жалеете? Часто ли ломаются билды? Часто ли натыкаетесь на баги? Хватает ли библиотек? Хватает ли тулинга? Как в поддержке и сопровождении? Н>Что хорошего дал вам .NET Core?
Здравствуйте, Нахлобуч, Вы писали:
Н>А вот у кого.NET Core в продакшене?
Чур тебя! Всякую бяку клиентам тащить...
Мы не то, что это "Федорино Коре", мы 2017-ую студию до сих пор не ставим! Спасибо, нахлебались, больше не хочется.
Походу, MS отчаянно машет саблей, рубя ветки под задницей. Дикие выходки им дорого обойдутся — поедут обратно в Индию танцевать.
Здравствуйте, Нахлобуч, Вы писали:
Н>Как живётся? Не жалеете? Часто ли ломаются билды? Часто ли натыкаетесь на баги? Хватает ли библиотек? Хватает ли тулинга? Как в поддержке и сопровождении?
Н>Что хорошего дал вам .NET Core?
Мы еще не в продакшн, но очень близки. Писал небольшую заметку по теме https://habrahabr.ru/post/312264/
Главный мотив для нас использовать .NET Core — импортозамещение. К 19-му году наши заказчики гос. компании должны будут перейти на СПО. Под СПО подразумевается ALT\Arch Linux и прочие российские дистрибутивы + российские клоны Postgre. Для нас это огромный рынок, существующая кодовая база большая и по быстрому переписать все на условную джаву невозможно.
Впечатление в целом положительное. Иногда раздражает тулинг (про танцы с форматом проектных файлов молчу). Например, переводили на .NET Core один старый проект с кучей resx файлов, при сборке dotnet.exe падает с ошибкой "Object reference not set to an instance of an object", просто в консоль выводит строкой без стэка и без намека что с этим делать. Взял исходники, собрал, продебажил, исправил, заслал PR на гитхаб, приняли — все круто. Во второй версии тулинга мое изменение потеряли, оставили старый код и ошибка вернулась, не знаю что сказать. В остальном все неплохо — код собирается, отладка работает, решарпер все нормально поддерживает, код писать можно.
Сам рантайм и стандартная библиотека не подводили, никаких сюрпризов вспомнить не могу.
Еще из плюсов бы добавил наличие исходников и подробные issues на гитхабе. Что весь процесс разработки открыт и прозрачен тоже считаю большим плюсом.
Ключевые библиотеки под .NET Core спортировали: JSON.NET, NEST, StackExchange.Redis, npgsql — все есть и работает. Ждем, когда ребята сделают в NLog поддержку второго стандарта. MiniProfiler тоже подтянулся.
Помимо кроссплатформенности из хорошего отметил бы возможность использовать докер. Как человек измученный windows installer, installshield и подобными очень давно ждал прихода докера в наш стэк.
Сравнить производительность еще не успели, да и будет сложно это сделать так как при миграции кода много чего переписывалось в силу разных причин.
Для новых приложений смело рекомендую использовать .NET Core, со старыми могут быть проблемы. Особенно если приложение активно сидит на виндовых фичах (реестр, wmi, performance counters) и имеет множество зависимостей.
Re[2]: Хипстеры, отзовитесь! А вот у кого.NET Core в продакшене?
Здравствуйте, kotov_a, Вы писали:
_>Мы еще не в продакшн, но очень близки. Писал небольшую заметку по теме https://habrahabr.ru/post/312264/
Про Mono почти не говорят на конференциях
Без комментариев
Затем для каждого csproj-файла нужно создать его аналог — project.json.
В августе 2017 года этого делать не надо.
Теперь конфигурации рекомендуется хранить в json файле.
В отдельных файлах, с возможностью наложения, с поддержкой переменных среды, командной строки и azure key vault. И xml никто не отменял.
MachineKey — Windows специфика, нет возможности получить уникальный идентификатор текущей машины.
MachineKey это не уникальный идентификатор машины, а ключ шифрования, привязанный к машине. Ничего windows-специфичного в нем нет.
Первую проблему можно решить поставив перед нашим приложением Apache с необходимым расширением и включив reverse proxy.
Apache в качестве reverse proxy? Серьезно?
Библиотеку для управления ACL еще не нашли.
Управления или проверки? Если проверки, то ADAL кору поддерживает, да и руками ADFS поверх OAuth2 реализовать несложно. А управление — вообще непонятно, у каждой платформы свои собственные ACL. И что ж это за кроссплатформенное решение, завязанное на права в AD?
_>Для новых приложений смело рекомендую использовать .NET Core
А я, по крайней мере до релиза 2.0, сильно не рекоменовал бы. Очень нестабильно. Тот же EFCore до сих пор некоторые совсем базовые штуки вроде Group By не поддерживает. А их попытка дропнуть поддержку .NET FW это вообще что то с чем то.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, kotov_a, Вы писали:
_>>Мы еще не в продакшн, но очень близки. Писал небольшую заметку по теме https://habrahabr.ru/post/312264/
AVK>
AVK>Про Mono почти не говорят на конференциях
AVK>Без комментариев
Имел в виду русскоязычные конференции, на доклады каких спикеров стоит обратить внимание?
AVK>
AVK>Затем для каждого csproj-файла нужно создать его аналог — project.json.
AVK>В августе 2017 года этого делать не надо.
На момент написания статьи (2016 год) был только project.json
AVK>
AVK>Теперь конфигурации рекомендуется хранить в json файле.
AVK>В отдельных файлах, с возможностью наложения, с поддержкой переменных среды, командной строки и azure key vault. И xml никто не отменял.
Конечно же никто не отменял, кому надо и ini-файл могут использовать. Я же говорю про способ, который идет из коробки с ASP.NET Core и на момент написание статьи System.Configuration еще не был портирован.
AVK>
AVK>MachineKey — Windows специфика, нет возможности получить уникальный идентификатор текущей машины.
AVK>MachineKey это не уникальный идентификатор машины, а ключ шифрования, привязанный к машине. Ничего windows-специфичного в нем нет.
Неправильно написал: есть MachineKey(Protect, Unprotect), которые во второй версии так и не спортировали и действительно реализовать это можно не только на Windows. Помимо это в нашем софте используется механизм лицензирования привязанный к конкретной машине (подобно лицензированию Windows: один ключ — одна машина), если подскажете как можно реализовать лицензирование с привязкой к конкретной машине в Linux — буду очень благодарен, проблема до сих пор актуальна.
AVK>
AVK>Первую проблему можно решить поставив перед нашим приложением Apache с необходимым расширением и включив reverse proxy.
AVK>Apache в качестве reverse proxy? Серьезно?
К сожалению да, нужна NTLM\Kerberos аутентификация без использования IIS. Из того что находил я есть apache + mod_auth_kerb или платная редакция nginx. Остановились пока на первом варианте. Для новых приложений сделали свой OpenId провайдер, для старых приложений нужно сохранить совместимость. Можете порекомендовать какие-то альтернативы?
AVK>
AVK>Библиотеку для управления ACL еще не нашли.
AVK>Управления или проверки? Если проверки, то ADAL кору поддерживает, да и руками ADFS поверх OAuth2 реализовать несложно. А управление — вообще непонятно, у каждой платформы свои собственные ACL. И что ж это за кроссплатформенное решение, завязанное на права в AD?
Управления и проверки, права (дескрипторы) должны хранится внутри системы (без прямой завязки на AD, но интеграция с ним должна быть, хотя бы для импорта учетных записей). Нужна возможность управлять правами доступа на объекты внутри нашей системы аналогичная возможностям Windows по раздаче прав на файлы (дескрипторы, наследования, разрешения, запреты, права на группы, свои кастомные разрешения). Есть ограничение: система старая, модель управления правами устоялась, все заказчики к ней привыкли. В Windows версии нашей системы используется RawSecurityDescriptor для AccessCheck вызываются виндовые функции. Уже после написания статьи на хабре, решили форкнуть RawSecurityDescriptor, написали свой AccessCheck и в принципе ок — формат дескриптора по сравнению с виндовым не изменился, по фукнционалу тоже не особо потеряли, кроссплатформенно.
_>>Для новых приложений смело рекомендую использовать .NET Core
AVK>А я, по крайней мере до релиза 2.0, сильно не рекоменовал бы. Очень нестабильно. Тот же EFCore до сих пор некоторые совсем базовые штуки вроде Group By не поддерживает. А их попытка дропнуть поддержку .NET FW это вообще что то с чем то.
Зачем же так обобщать: EF выходит за рамки рантайм + стандартная библиотека, можно решать большой пласт задач не используя ORM. А до выхода второй версии, судя по issues на гитбхаб, осталось не так много времени, в этом квартале должен быть релиз.
Кстати, забыл еще написать, что WCF (server side) похоже в .NET Core мы не увидим, тоже может стать серьезной проблеме при миграции существующего приложения.
Re[4]: Хипстеры, отзовитесь! А вот у кого.NET Core в продакшене?
_>Кстати, забыл еще написать, что WCF (server side) похоже в .NET Core мы не увидим, тоже может стать серьезной проблеме при миграции существующего приложения.
Возможно и увидим. Все таки в .Net Core 2 появится полная поддержка XML, а там и по просьбам трудящихся ...
и солнце б утром не вставало, когда бы не было меня
Re[4]: Хипстеры, отзовитесь! А вот у кого.NET Core в продакшене?
AVK>>Без комментариев _>Имел в виду русскоязычные конференции, на доклады каких спикеров стоит обратить внимание?
Да дело не в этом, просто очень органично вместе с сабжем сей аргумент смотрится.
AVK>>В августе 2017 года этого делать не надо. _>На момент написания статьи (2016 год) был только project.json
Это понятно. Но сейчас этго делать не стоит.
AVK>>В отдельных файлах, с возможностью наложения, с поддержкой переменных среды, командной строки и azure key vault. И xml никто не отменял. _>Конечно же никто не отменял, кому надо и ini-файл могут использовать. Я же говорю про способ, который идет из коробки с ASP.NET Core и на момент написание статьи System.Configuration еще не был портирован.
Ты не понял. Для Microsoft.Extensions.Configuration есть несколько источников, а не один только json. В том числе и xml.
_>Помимо это в нашем софте используется механизм лицензирования привязанный к конкретной машине (подобно лицензированию Windows: один ключ — одна машина)
А ничего что этот ключ вполне может поменяться?
_>, если подскажете как можно реализовать лицензирование с привязкой к конкретной машине в Linux — буду очень благодарен, проблема до сих пор актуальна.
Нормальный способ — только аппаратные ключи. Но я бы просто забил. Не верю я что кто то, способный заплатить за серверную лицензию будет софт пиратить.
_>Можете порекомендовать какие-то альтернативы?
nginx. И перейти на OAuth2, Identity Server вроде умеет искаропки. Но мне все равно непонятно — зачем вам NTLM без AD.
_>Зачем же так обобщать: EF выходит за рамки рантайм + стандартная библиотека
Тем не менее это штатный способ работы с БД. Да и с ASP.NET Core не все пока шоколадно.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, Нахлобуч, Вы писали:
Н>Как живётся? Не жалеете? Часто ли ломаются билды? Часто ли натыкаетесь на баги? Хватает ли библиотек? Хватает ли тулинга? Как в поддержке и сопровождении?
Делали проект на нем год назад, микросервис платежей, Web API. Из конторы уже ушел, а сервис вполне себе вертится в продакшене. Всего хватало и нравилось больше обычного ДотНет-а, это приятное ощущение легкости
Н>Что хорошего дал вам .NET Core?
Задачи иметь кроссплатформенность не ставилось, поэтому .NET Core был выбран ради ASP.NET Core. А там плюсов полно: единый стек Web API и MVC, выразительный Dependency Injection, всякие Microsoft.Extensions.
Для новых проектов, если это не Windows GUI, я бы выбирал .NET Core.
Re: Хипстеры, отзовитесь! А вот у кого.NET Core в продакшене?
Здравствуйте, Нахлобуч, Вы писали:
Н>Как живётся? Не жалеете? Часто ли ломаются билды? Часто ли натыкаетесь на баги? Хватает ли библиотек? Хватает ли тулинга? Как в поддержке и сопровождении? Н>Что хорошего дал вам .NET Core?
В целом нормальные впечатления, но часто не хватает нужных библиотек. Приходится держать в голове, что библиотеки которые тебе нравятся и к которым привык еще не портированы. Так что прежде чем писать — нужно проверить что будете использовать. Например, NHibernate еще не портировали.
Еще не понравилось поведение среды. В частности был у меня случай. Нажимаешь в студии ребилд проекта, студия долго билдит, показывает логи, потом показывает типа копирует, затем 0 ошибок и полный успех. Запускаешь сервис все та же ошибка. Смотришь в папку bin. А там даты месячной давности. Что делала студия и куда она сбилдила для меня по прежнему осталось загадкой. dotnet rebuild в командной строке — это единственное чем удалось побороть такое поведение.
Re[2]: Хипстеры, отзовитесь! А вот у кого.NET Core в продакшене?
Здравствуйте, MxMsk, Вы писали:
MM>Задачи иметь кроссплатформенность не ставилось, поэтому .NET Core был выбран ради ASP.NET Core. А там плюсов полно: единый стек Web API и MVC, выразительный Dependency Injection, всякие Microsoft.Extensions.
ASP.NET Core работает и под FW.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
