Comments 32
Что в конечном итоге с производительностью?
Спасибо. Позновательно.
Мало.
Про Mono почти не говорят на конференциях, такое чувство, что технологию никто не использует
Кроме Unity и Xamarin приложений ;-)
А проект действительно крупный?
Меня недавно от такого шага остановило то, что в .NET Core по бороде пошел Reflection API, который я активно использовал
Меня недавно от такого шага остановило то, что в .NET Core по бороде пошел Reflection API, который я активно использовал
Единственная проблема, что старый солюшен с csproj-проектами перестанет работать, чтобы оба проекта работали side by side есть решение. Выглядит довольно странно, но работает.
Чтобы решить эту проблему я разделил проект на 2 директории:
ИМЯ_ПРОЕКТА и ИМЯ_ПРОЕКТА.Net4. В первой директории оставил: xproj-файл, project.json, весь общий код, а также код, необходимый для .NET Core-версии. Во второй: csproj-файл, packages.config и код, необходимый для .NET Framework 4.0-версии (файлы с общим кодом добавляются в csproj-файл в виде ссылок).
С этим .NET Core иногда нужно столько переписывать, что пункт 3 из вашего списка не кажется таким уж проблемным. То, что я увидел в .NET Core:
1. Полностью переделана конфигурация. Т.е. сегодня модно в JSON, завтра в protobuf будет. Придётся переписывать весь конфиг для проектов.
2. Очень сильно перекочеврыжен рефлекшен. В большинстве случаев решается через GetTypeInfo (обезьянкой ходишь по коду и вставляешь эту строчку). Опять же, переписывать кучу всего.
3. Потеря кучи библиотек, или сидеть ждать, когда авторы переделают, или пытаться самостоятельно, если исходники есть. Банальный log4net не работает
4. Постоянная смена API. Например, Kestrel с каждой версией полностью меняет API. При этом «каждая» версия это (1.0.0-beta, 1.0.0-rc, 1.0.0). До кучи бардак в репозиториях — тот же кестрел лежит под тремя именами.
5. Периодически мелкое изменение API стандартных библиотек в самых неожиданных местах. Например у RSA нельзя получить XML с параметрами. Т.е. весь код надо обкладывать ифами и проводить тестирование
При этом по факту, под mono работает то, что и вроде бы и не должно работать, например HttpListener. Скорость — не ясно, но числодробилки на .NET реализовывать странно, а в бизнес.приложениях всё равно всё упирается в базу данных, или как у вас в SOAP, который архитектурно никогда быстрым не был.
1. Полностью переделана конфигурация. Т.е. сегодня модно в JSON, завтра в protobuf будет. Придётся переписывать весь конфиг для проектов.
2. Очень сильно перекочеврыжен рефлекшен. В большинстве случаев решается через GetTypeInfo (обезьянкой ходишь по коду и вставляешь эту строчку). Опять же, переписывать кучу всего.
3. Потеря кучи библиотек, или сидеть ждать, когда авторы переделают, или пытаться самостоятельно, если исходники есть. Банальный log4net не работает
4. Постоянная смена API. Например, Kestrel с каждой версией полностью меняет API. При этом «каждая» версия это (1.0.0-beta, 1.0.0-rc, 1.0.0). До кучи бардак в репозиториях — тот же кестрел лежит под тремя именами.
5. Периодически мелкое изменение API стандартных библиотек в самых неожиданных местах. Например у RSA нельзя получить XML с параметрами. Т.е. весь код надо обкладывать ифами и проводить тестирование
При этом по факту, под mono работает то, что и вроде бы и не должно работать, например HttpListener. Скорость — не ясно, но числодробилки на .NET реализовывать странно, а в бизнес.приложениях всё равно всё упирается в базу данных, или как у вас в SOAP, который архитектурно никогда быстрым не был.
По пунткам:
Это и пугает, фидбека о технологии очень мало, неизвестно, что ожидать. Проблемы с базой действительно возникают (поэтому используем Redis), но хотелось бы, чтобы рантайм языка программирования (как и стандартная библиотеки) не подводили и работали быстро.
- Верно, но на фоне объема нашего приложение сложность чтения настроек слишком мала, можно пренебречь.
- Согласен полностью, мартышкин труд.
- Мы используем: Newtonsoft.Json, StackExchange.Redis.StrongName, Npgsql. Такая проблема действительно есть, сам жду когда спортируют мой любимый MiniProfiler. NLog не используете?
- Именно поэтому ждал RTM, чтобы не вникать в эти мелкие изменения. Сейчас такой проблемы не заметил, на версию 1.0.1 обновились без сложностей.
- Все верно, так и поступили.
Это и пугает, фидбека о технологии очень мало, неизвестно, что ожидать. Проблемы с базой действительно возникают (поэтому используем Redis), но хотелось бы, чтобы рантайм языка программирования (как и стандартная библиотеки) не подводили и работали быстро.
3. Исторически сложился log4net — особого смысла менять, пока не видим.
Пока, имхо, стоит ждать .NET Core 2.0, смотреть что у них получится, заодно фидбека и best practices накопится. С Mono, если удастся подобрать идентичное железо попробую натравить свою числодробилку, оптимизированную под .NET, на Mono и .NET Core, посмотрю на результаты. Если не забуду, отпишусь :)
Пока, имхо, стоит ждать .NET Core 2.0, смотреть что у них получится, заодно фидбека и best practices накопится. С Mono, если удастся подобрать идентичное железо попробую натравить свою числодробилку, оптимизированную под .NET, на Mono и .NET Core, посмотрю на результаты. Если не забуду, отпишусь :)
Свойство Assembly у экземпляра Type — чтобы получить описание сборки у типа необходимо использовать метод-расширение GetTypeInfo(). Ломает совместимость с текущим кодом, особенно в ресурсных файлах.
Это является проблемой только тогда, когда нужно поддерживать 2 версии проекта (для .NET Core и .NET Framework 4.0).
Чтобы сгладить различия между разными реализациями Reflection, я использую полифиллы (например, TypeInfo.cs и TypeExtensions.cs).
С генерацией ресурсных файлов сложнее. Пришлось отказаться от стандартных генераторов в пользу собственного, написанного под Sake и KoreBuild.
Воу, вот за генератор ресурсов спасибо.
Эх, а он у вас тоже только строковые ресурсы поддерживает, да? Никаких там ImageList в него не запаковать? :(
Да, только строковые ресурсы. За основу брал код стандартного генератора от Microsoft.
По поводу SOAP немного не понял. Что именно не работает в .NET Core: HttpBinding вообще или всего лишь шаринг порта + активация?
Нет веб-сервисов как таковых (WCF, aspx, svc и так далее). Соответственно, байндингов тоже нет. Есть ASP.NET Core, который из коробки поддерживает только REST.
Там в примере с msdn есть строчка:
var encoder = binding.CreateBindingElements().Find<MessageEncodingBindingElement>()?.CreateMessageEncoderFactory().Encoder;Значит, как минимум библиотеки WCF доступны.
Полагаю, строчка относится к .NET 4.x. В .NET Core есть поддержка клиентского WCF и есть всеобщий молебен с просьбами поддержать серверный. Там же есть несколько ссылок на проекты, которые в какой-то мере могут заменить WCF.
Немного пояснений по svc-файлам. svc-файл — это не веб-сервис как таковой, а механизм его активации. Когда запрос попадает на svc-файл, обработчик svc-файлов конструирует и настраивает ServiceHost, после чего соответствующий URL перестает обслуживаться IIS и начинает обслуживаться ServiceHost.
После этого те запросы, которые пришли на svc-файл в IIS, тихонько "подкладываются" во входную очередь http-транспорта.
А как много времени на это все ушло? Были ли какие-то ошибки компиляции, которые нужно было долго исправлять?
> Что будет с Mono вне Xamarin вопрос. Будет ли Microsoft одновременно развивать 2 конкурирующие реализации .NET?
у Mono Project есть публичные доски в трелло для слежки за процессом разработки, оно же и является roadmap'ом
https://trello.com/monoproject1
у Mono Project есть публичные доски в трелло для слежки за процессом разработки, оно же и является roadmap'ом
https://trello.com/monoproject1
Хороший вектор на переход к Core. По поводу аутентификации была такая же проблема, находил статейку где учётки и права можно с IIS портировать в базейку, а её уже юзать под Core Identity. Я конечно не вижу всей Вашей картины, но покапать можно туда.
Удивляет, что не упомянуты проблемы сторонних библиотек. У нас в солюшене 100+ проектов и десятки nuget пакетов и сторонних библиотек, далеко не все из которых имеют поддержку .net core и в принципе могут работать на Linux, даже под mono. Не очень ясно, когда можно будет взлетать со всем этим хозяйством.
переход на core вряд ли сейчас оправдан — майкрософт может еше не один раз перевернуть там все с ног на голову как недавно.
Лично я не вижу пока особого смысла запускать .NET проекты под линуксом. Обычно если разраб выбирает .NET то он выбирает и остальной стек майкрософта начиная с самой платформы и заканчивая mssql например. Опять же множество библиотек и наработок которые не будут выполнятся под линуксом пока не будут портированы.
ИМХО пока основная фишка core — это опенсорс. Но с таким же успехом можно писать приложения на яве — тоже как правило опенсорс и кросплатформеность, Не говоря про количество библиотек несравнимое со всем дотнетом вместе взятым.
.
.
Лично я не вижу пока особого смысла запускать .NET проекты под линуксом. Обычно если разраб выбирает .NET то он выбирает и остальной стек майкрософта начиная с самой платформы и заканчивая mssql например. Опять же множество библиотек и наработок которые не будут выполнятся под линуксом пока не будут портированы.
ИМХО пока основная фишка core — это опенсорс. Но с таким же успехом можно писать приложения на яве — тоже как правило опенсорс и кросплатформеность, Не говоря про количество библиотек несравнимое со всем дотнетом вместе взятым.
.
.
Где-то с полгода назад мы пробовали перевести крупный .NET проект с 12-летней историей на Mono. В связи с плавным переходом на микросервисную архитекруту, просто завораживала возможность ранать и деплоить все единообразно(docker, kubernetes, все дела).
За несколько человеко-недель удалось собрать проект под моно и поправить невероятно странные ошибки, которые возникали из-за отличий работы неоторых библиотек на .NET и Mono(в частности ReLinq просто собирал разные expression trees под обеими платформами). Потом запустили перформанс тесты, которые у нас есть в неплохом количестве. Результаты оказались удручающими. Некоторые сервисы просели в разы. У нас в проекте много бизнес-логики, но также очень много работы с деревьями выражений, свой QueryProvider. Пытались разобраться какие места конкретно тормозят, но оказалось не так-то просто. Профайлер под моно грустный(как и monodevelop). Пытались вырезать из конкретного сервиса логику, до тех пор пока не доберемся до места где происходит различие, но не особо получилось. Кажется, что рефлексия, работа со строками, сборка мусора под mono проседает, но 100% до конца не разобрались. В общем провал.
Ждем нативного докера под windows.
За несколько человеко-недель удалось собрать проект под моно и поправить невероятно странные ошибки, которые возникали из-за отличий работы неоторых библиотек на .NET и Mono(в частности ReLinq просто собирал разные expression trees под обеими платформами). Потом запустили перформанс тесты, которые у нас есть в неплохом количестве. Результаты оказались удручающими. Некоторые сервисы просели в разы. У нас в проекте много бизнес-логики, но также очень много работы с деревьями выражений, свой QueryProvider. Пытались разобраться какие места конкретно тормозят, но оказалось не так-то просто. Профайлер под моно грустный(как и monodevelop). Пытались вырезать из конкретного сервиса логику, до тех пор пока не доберемся до места где происходит различие, но не особо получилось. Кажется, что рефлексия, работа со строками, сборка мусора под mono проседает, но 100% до конца не разобрались. В общем провал.
Ждем нативного докера под windows.
Sign up to leave a comment.
Портирование большого проекта на .NET Core