Если вы знакомы с winforms, то должны помнить что в них каждый контрол это отдельный хендл дочернего окна. Это системный ресурс который ограничен. На экране большой площади у вас может чаще возникать ситуация когда хендлов не хватает.
Винформс нужно оставить в прошлом.
Попробуйте наши демки. Мне ещё никто не жаловался что они тормозят. Все прекрасно работает. В том числе и на 4к
Windows однозначно более дружелюбна к зоопарку разного железа. Особенно если год выпуска железа примерно совпадает с жизненным циклом версии Windows, а вот если не совпадает ... то тогда линукс в помощь )).
У меня такая теория: если Linux правильно встал на ваше железо, он будет там работать стабильнее чем Windows и будет меньше всякого навязывать чего вы не просили его делать.
Дело в том, что затраты на создание Copilot просто несоизмеримы с затратами на такой плагин как решарпер и мы не знаем, насколько Copilot финансово успешен. Я бы не рискнул делать что то платное под VSCode
Если проект мертвый, то проще конечно его не трогать и как то запускать под wine.
Если проект нужно развивать, то для такого проекта созданного на 30 летней технологии должно совпасть несколько факторов: нужно найти собственника который готов вкладывать в проект на легаси, найти команду которая умеет и возьмётся разрабатывать винформс. Многие разработчики попробовав xaml платформы не возвращаются в винформс. Поэтому команду найти будет проблематично, но иногда такие проекты ещё встречаются.
Winforms очень устарел. Он создавался когда ещё были ЭЛТ мониторы. И разброс разрешений мониторов был небольшим. Сегодня программу могут запустить и на FHD мониторе и на широченном 8к. Winforms ни по производительности рендеринга ни по адаптируемости не вывезет это.
Не так давно появился XAML previewer экстеншен для VSCode. На мой взгляд, VSCode для NET в принципе не слишком удобный. Он создавался для веб разработки, а поддержку NET прикручивали к нему сбоку.
Бесплатность этого продукта сыграла с ним злую шутку: невозможно успешно продавать экстеншены к бесплатному продукту. Поэтому в экосистеме VSCode невозможен например Решарпер.
Предлагаю сойтись на мнении что нужно брать лучшее из обоих миров.
Давайте вспомним инфоповод к которому была написана статья. Окончание жизни Win10. Это значит что исправное железо которое стоит в офисе под столом или на столе у пользователя Microsoft предлагает вам выбросить. Есть вариант установить на него Linux и жить дальше спокойно. Разумеется, этот вариант подойдет не всем. Мы только говорим что есть такая возможность.
Спасибо что спросили. Попробую исправить ситуацию.
Если вы мигрируете с WinForms, будет сложнее. Потому что платформы идеологически сильно разные. Почти никто не делал WinForms приложения по MVVM паттерну. А это значит что в коде будет куча обработчиков сообщений которые придется переписать на команды во ViewModel. Еще миграция усложняется тем, что в винфоррмс можно было делать кастомную отрисовку. Этот код скорее всего придется выкидывать и переписывать на xaml стили. Но самая "нудятина" при миграции -: по огромной портянке в InitializeComponent понять что это такое, как оно должно работать. Вот с этой частью может помочь наш проект https://github.com/MICVGLOB/WinForms2AvaloniaConverter . Можно почитать в ридми и в исходниках как он работает. Если совсем коротко, он создаст xaml с Avalonia элементами UI которые функционально соответствуют и называются так же как элементы конвертируемой формы. Почти всегда за конвертером нужно подчищать лайаут, каким то элементам он не может найти прямых аналогов, но все равно он здорово нам сэкономил время когда мы мигрировали оргомный проект состоящий из более 300 форм на Avalonia.
Если мигрируете с WPF, будет проще. Однозначно сохранится слой ViewModel если приложение было написано правильно. Во View придется поискать аналоги некоторых элементов. Именование немного различается. Кастомизациия в XAML немного различается. В авлонии нет триггеров. Вместо них, есть система стилей.
Сложности, которые поджидают при миграции и с WinForms и с WPF: не используйте нигде пути в виде строковых констант. Лучше Path.Combine. Кодировки: если исходный код содержит русские символы, винда сохраняет такое обычно в своей кодировке. Мы конвертировали все в UTF-8 BOM и написали диагностики которые бьют по рукам тем кто пытается это соглашение нарушать. Environment.SpecialFolder в линуксах работают немного по другому. Читайте документацию. Винда игнорирует регистр в названиях файлов. Почти все, кто пытается впервые собрать свой проект под Linux, получают ошибки которые вызваны тем, что в csproj файл упомянут например MyClass.cs. А в папке лежит myclass.cs. Проблемы с клипбордом. Он на линуксах работает немного не так как как все привыкли. Проблемы с переводом строк. Например, если у вас будет sh файл с виндовым окончанием строк - CRLF, он ни за что не выполнится. Будут странные ошибки. Dos2Unix в помощь.
Вот, что сходу вспомнил ). Если вам будет нужна помощь с миграцией на Avalonia, напишите нам https://t.me/emxControls. Постараемся помочь.
По моему мнению, с Линукс меньше проблем чем с видной.
Правильно настроенный системник с Линукс скорее морально устареет чем сломается. А переустановка винды у многих пользователей довольно частая процедура.
Мне очень не нравится в современных виндах неотключаемая телеметрия, не отключаемый дефендер, некоторые настройки просто не работают или включаются назад сами. Привязка локальных учёток пользователей к облаку.
Держать в штате админа который ничего не умеет вам выйдет дороже ).
Универсального ответа для всех нет. Кому то выгоднее будет перейти на win11 и жить спокойно как раньше, но есть и вариант плавно мигрировать на Линукс. Технологический стек описанный в статье это позволяет. Однозначно, Я не советую оставлять парк машин предприятия на ОС без обновлений. Это безответственное решение.
Наверное нужно пояснить ещё. Идея не в том чтобы все сидели параллельно на двух ос. Предлагается плавный переход. Например в этом месяце мы переводим на Линукс кладовщика. В следующем - какой нибудь ещё отдел. А Мариванну не будем вообще трогать. Пускай на винде сидит. Ей пару месяцев до пенсии. Нет смысла учить..
Кроссплатформенный софт может сделать кто угодно. Это может быть кто то из своих айтишников если им хватит знаний или можно кого то привлечь со стороны.
"Сидеть параллельно на Windows и Linux.". Да, а в чем проблема? Если задаваться целью всех перевести на Linux к определенной дате, это будет сильно дороже чем плавный переход.
"необходимо перевести Всю организацию на линукс". Про это не написали явно в статье, но вот как раз предлагаемый в ней стек технологий позволяет делать приложения которые работают и под Windows и под Линукс. Поэтому сразу и всех переводить не нужно. Можно это делать выборочно и с умом.
Про правильную эксплуатацию вычислительной техники в организациях. Вспоминается недавний коллапс у Аэрофлота. По словам людей, близких к их айти, там эксплуатировалась ещё древняя win xp. Денег всегда не хватает, но оставлять парк машин на не обновляемой ОС - разгильдяйство.
Насколько мне известно, было решено выкинуть старые девтулзы потому что их не хотелось поддерживать. Этот проект требовал внимания разработчиков при каждом обновлении. Надеюсь они найдут какой-то вариант который будет всем удобен. Понятно, что все разработчики не перейдут на платные дев тулзы.
Статья хоть и своеобразно но рассказывает что сейчас на Линукс есть все: и среды разработки и фреймворк для мультиплатформенной разработки и даже какая то экосистема вендоров которые готовы помогать коммерческим проектам. Чего по вашему мнению ещё не хватает?
Если вы знакомы с winforms, то должны помнить что в них каждый контрол это отдельный хендл дочернего окна. Это системный ресурс который ограничен. На экране большой площади у вас может чаще возникать ситуация когда хендлов не хватает.
Винформс нужно оставить в прошлом.
Попробуйте наши демки. Мне ещё никто не жаловался что они тормозят. Все прекрасно работает. В том числе и на 4к
https://github.com/Eremex/controls-demo
Там в релизах есть собранные бинарники под вин и под Линукс.
"IDEA комунити". Это из java мира. Не могу коментировать, не разбираюсь в их экосистеме.
Windows однозначно более дружелюбна к зоопарку разного железа. Особенно если год выпуска железа примерно совпадает с жизненным циклом версии Windows, а вот если не совпадает ... то тогда линукс в помощь )).
У меня такая теория: если Linux правильно встал на ваше железо, он будет там работать стабильнее чем Windows и будет меньше всякого навязывать чего вы не просили его делать.
Дело в том, что затраты на создание Copilot просто несоизмеримы с затратами на такой плагин как решарпер и мы не знаем, насколько Copilot финансово успешен. Я бы не рискнул делать что то платное под VSCode
Я имел ввиду не техническую сторону, а финансовую. Сложно предлагать платное там где люди не приучены платить.
Если проект мертвый, то проще конечно его не трогать и как то запускать под wine.
Если проект нужно развивать, то для такого проекта созданного на 30 летней технологии должно совпасть несколько факторов: нужно найти собственника который готов вкладывать в проект на легаси, найти команду которая умеет и возьмётся разрабатывать винформс. Многие разработчики попробовав xaml платформы не возвращаются в винформс. Поэтому команду найти будет проблематично, но иногда такие проекты ещё встречаются.
Winforms очень устарел. Он создавался когда ещё были ЭЛТ мониторы. И разброс разрешений мониторов был небольшим. Сегодня программу могут запустить и на FHD мониторе и на широченном 8к. Winforms ни по производительности рендеринга ни по адаптируемости не вывезет это.
Не так давно появился XAML previewer экстеншен для VSCode. На мой взгляд, VSCode для NET в принципе не слишком удобный. Он создавался для веб разработки, а поддержку NET прикручивали к нему сбоку.
Бесплатность этого продукта сыграла с ним злую шутку: невозможно успешно продавать экстеншены к бесплатному продукту. Поэтому в экосистеме VSCode невозможен например Решарпер.
Если я буду отвечать, получится прям холивар ).
Предлагаю сойтись на мнении что нужно брать лучшее из обоих миров.
Давайте вспомним инфоповод к которому была написана статья. Окончание жизни Win10. Это значит что исправное железо которое стоит в офисе под столом или на столе у пользователя Microsoft предлагает вам выбросить. Есть вариант установить на него Linux и жить дальше спокойно. Разумеется, этот вариант подойдет не всем. Мы только говорим что есть такая возможность.
Спасибо что спросили. Попробую исправить ситуацию.
Если вы мигрируете с WinForms, будет сложнее. Потому что платформы идеологически сильно разные. Почти никто не делал WinForms приложения по MVVM паттерну. А это значит что в коде будет куча обработчиков сообщений которые придется переписать на команды во ViewModel. Еще миграция усложняется тем, что в винфоррмс можно было делать кастомную отрисовку. Этот код скорее всего придется выкидывать и переписывать на xaml стили. Но самая "нудятина" при миграции -: по огромной портянке в InitializeComponent понять что это такое, как оно должно работать. Вот с этой частью может помочь наш проект https://github.com/MICVGLOB/WinForms2AvaloniaConverter . Можно почитать в ридми и в исходниках как он работает. Если совсем коротко, он создаст xaml с Avalonia элементами UI которые функционально соответствуют и называются так же как элементы конвертируемой формы. Почти всегда за конвертером нужно подчищать лайаут, каким то элементам он не может найти прямых аналогов, но все равно он здорово нам сэкономил время когда мы мигрировали оргомный проект состоящий из более 300 форм на Avalonia.
Если мигрируете с WPF, будет проще. Однозначно сохранится слой ViewModel если приложение было написано правильно. Во View придется поискать аналоги некоторых элементов. Именование немного различается. Кастомизациия в XAML немного различается. В авлонии нет триггеров. Вместо них, есть система стилей.
Сложности, которые поджидают при миграции и с WinForms и с WPF: не используйте нигде пути в виде строковых констант. Лучше Path.Combine. Кодировки: если исходный код содержит русские символы, винда сохраняет такое обычно в своей кодировке. Мы конвертировали все в UTF-8 BOM и написали диагностики которые бьют по рукам тем кто пытается это соглашение нарушать. Environment.SpecialFolder в линуксах работают немного по другому. Читайте документацию. Винда игнорирует регистр в названиях файлов. Почти все, кто пытается впервые собрать свой проект под Linux, получают ошибки которые вызваны тем, что в csproj файл упомянут например MyClass.cs. А в папке лежит myclass.cs. Проблемы с клипбордом. Он на линуксах работает немного не так как как все привыкли. Проблемы с переводом строк. Например, если у вас будет sh файл с виндовым окончанием строк - CRLF, он ни за что не выполнится. Будут странные ошибки. Dos2Unix в помощь.
Вот, что сходу вспомнил ). Если вам будет нужна помощь с миграцией на Avalonia, напишите нам https://t.me/emxControls. Постараемся помочь.
"почему надо выбирать именно вариант с линуксом."
По моему мнению, с Линукс меньше проблем чем с видной.
Правильно настроенный системник с Линукс скорее морально устареет чем сломается. А переустановка винды у многих пользователей довольно частая процедура.
Мне очень не нравится в современных виндах неотключаемая телеметрия, не отключаемый дефендер, некоторые настройки просто не работают или включаются назад сами. Привязка локальных учёток пользователей к облаку.
Спасибо за высокую оценку.
Я все ещё не верю в бизнес модель с бесплатным предложением )
"куча потраченных ресурсов"
Я бы назвал Инвестиция в развитие.
Держать в штате админа который ничего не умеет вам выйдет дороже ).
Универсального ответа для всех нет. Кому то выгоднее будет перейти на win11 и жить спокойно как раньше, но есть и вариант плавно мигрировать на Линукс. Технологический стек описанный в статье это позволяет. Однозначно, Я не советую оставлять парк машин предприятия на ОС без обновлений. Это безответственное решение.
Внутренний софт переписать на кроссплатформ. Остальному софту который нужен для работы подобрать аналоги под Линукс.
Просто не нанимайте админов которые не знают Линукс. Найдите нормальных админов.
Зачем это нужно, Я уже написал. Чтобы не было как у Аэрофлота.
Наверное нужно пояснить ещё. Идея не в том чтобы все сидели параллельно на двух ос. Предлагается плавный переход. Например в этом месяце мы переводим на Линукс кладовщика. В следующем - какой нибудь ещё отдел. А Мариванну не будем вообще трогать. Пускай на винде сидит. Ей пару месяцев до пенсии. Нет смысла учить..
Я думаю вы поняли идею )
Кроссплатформенный софт может сделать кто угодно. Это может быть кто то из своих айтишников если им хватит знаний или можно кого то привлечь со стороны.
"Сидеть параллельно на Windows и Linux.". Да, а в чем проблема? Если задаваться целью всех перевести на Linux к определенной дате, это будет сильно дороже чем плавный переход.
"необходимо перевести Всю организацию на линукс". Про это не написали явно в статье, но вот как раз предлагаемый в ней стек технологий позволяет делать приложения которые работают и под Windows и под Линукс. Поэтому сразу и всех переводить не нужно. Можно это делать выборочно и с умом.
Про правильную эксплуатацию вычислительной техники в организациях. Вспоминается недавний коллапс у Аэрофлота. По словам людей, близких к их айти, там эксплуатировалась ещё древняя win xp. Денег всегда не хватает, но оставлять парк машин на не обновляемой ОС - разгильдяйство.
Да, этот момент многим не понравился.
Насколько мне известно, было решено выкинуть старые девтулзы потому что их не хотелось поддерживать. Этот проект требовал внимания разработчиков при каждом обновлении. Надеюсь они найдут какой-то вариант который будет всем удобен. Понятно, что все разработчики не перейдут на платные дев тулзы.
"никто не будет на Linux переходить"
Статья хоть и своеобразно но рассказывает что сейчас на Линукс есть все: и среды разработки и фреймворк для мультиплатформенной разработки и даже какая то экосистема вендоров которые готовы помогать коммерческим проектам. Чего по вашему мнению ещё не хватает?
Вы не так прочитали. Конец эпохи win10 а не Windows же )
А как оно работает у вас? Доступ к железу на server side? И на одной машине вместо нормального десктоп приложения к вас клиент и сервер?