Здравствуйте, okon, Вы писали:
O>Вот одна из хороших выбранных стратегий то что .NET Core кроссплатформен. O>Но зачем туда пихать вещи которые не кроссплатформены, например WinForms или WPF.
Потому что это обман и кроссплафторменности нет. С каждым днём появляются новые программисты. Далеко не все из них знают историю .NET Framework начиная с первых версий. А за эти годы очень сильно развились действительно кроссплатформенные решения, которые заставляют .NET глотать пыль далеко позади в канаве. Причём возможности настоящих кроссплатформенных решений многократно выше. Менеджерам майкрософт всё равно, что там потом будут делать программисты, им нужно продвигать свои решения.
Вот у тебя же в комментарии "не кроссплатформены, например WinForms или WPF" и всё равно пишешь "одна из хороших выбранных стратегий то что .NET Core кроссплатформен". На лицо логическое противоречие, но я вижу, что обман удался. Точно так же майкрософт обманывали с первых версий .NET обещая теоретическую кроссплатформенность, но в итоге нормально всё это будет работать только на винде. Более того, всё это потом отправится на помойку истории, создадут следующую версию, а на эту забьют.
Казалось бы ерунда, ну и что такого. Но изначальный выбор здесь такой, или создаёшь истинно кроссплатформенное приложение, которое через десятки лет будет запускаться на разных операционках, или придаток к очередному виндовому фреймворку, который выйдет из моды через несколько лет и тянет с собой кучу ненужных зависмостей.
Здравствуйте, okon, Вы писали:
O>Здравствуйте, varenikAA, Вы писали:
AA>>Здравствуйте, okon, Вы писали:
O>>>Вот одна из хороших выбранных стратегий то что .NET Core кроссплатформен. O>>>Но зачем туда пихать вещи которые не кроссплатформены, например WinForms или WPF.
AA>>Потому что .Net 4.8 последняя будет. .Net 5.0 — это уже полностью Core, поэтому и пихают, куда девать то? Почитайте roadmap.
O>Да знаю, вопрос только зачем это все в одну кучу смешивать, кроссплатформенность и виндовую платформу. O>Просто получается крайне не удобно это все разрабатывать, каждый раз используя любую фичу которая как-то немного зависит от платформы приходится беспокоиться а не вылезет ли там предупреждение что поддерживается только под Windows.
Потому-то меня и мучают постоянно приступы заюзать лисп, ракет или ним, на крайняк d, rust, go.
Но, это узкая ниша.
сильно беспокоится не стоит, ведь базовые компоненты наверняка проходят авто-тесты на чистоту кроссплатформенности(не проверял).
На крайняк всегда можно соскочить на java|kontlin если нравятся ВМ, но по опыту собеседования (правда это было давно), там требования к базовым знаниям(особенности ООП java, коллекции, размерности и т.п.) гораздо выше чем в dotnet.
фактически требуется сертификат.
O>>Но зачем туда пихать вещи которые не кроссплатформены, например WinForms или WPF. G>Что значит "пихать" ? WPF для .NET Core это отдельный пакет и даже отдельный проект на GitHub. В самом .NET Core нет ничего от WPF.
Пихать больше в продуктовом смысле, пишут типа "мы в .NET Core включили" сразу ассоциации с кросплатформенностью потом бац "Winforms / WPF".
мне кажется корректнее было бы в релизе .NET Core озвучивать только вещи которые кросплатформенны, и не включили WPF, а сделали WPF который может работать с .NET Core.
G>Для этого есть .NET Standard. Если пакет таргетит .NET Standard, то тыможешь узнать с какими рантаймами он гарантированно совместим https://dotnet.microsoft.com/platform/dotnet-standard G>Все что выходит за пределы .NET Standard скорее всего не будет работать на каких-то плаформах или таргетах для .NET Core
Не попадалась ли нормальная документация где можно было бы увидеть таблицу что и где поддерживается ?
O>>Есть ли где-то сводки что протестировано на разных платформах и работает +- одинаково, а что существенно отличается ? G>https://dotnet.microsoft.com/platform/dotnet-standard
Тут я нашел только очень краткую сводку, хотелось бы хотя бы детализация до сборока/класс. А в колонках платформы с флажками работает или частично работает/ совсем не работает.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
O>>>Но зачем туда пихать вещи которые не кроссплатформены, например WinForms или WPF. G>>Что значит "пихать" ? WPF для .NET Core это отдельный пакет и даже отдельный проект на GitHub. В самом .NET Core нет ничего от WPF.
O>Пихать больше в продуктовом смысле, пишут типа "мы в .NET Core включили" сразу ассоциации с кросплатформенностью потом бац "Winforms / WPF". O>мне кажется корректнее было бы в релизе .NET Core озвучивать только вещи которые кросплатформенны, и не включили WPF, а сделали WPF который может работать с .NET Core.
То есть вопрос только в названии?
G>>Для этого есть .NET Standard. Если пакет таргетит .NET Standard, то тыможешь узнать с какими рантаймами он гарантированно совместим https://dotnet.microsoft.com/platform/dotnet-standard G>>Все что выходит за пределы .NET Standard скорее всего не будет работать на каких-то плаформах или таргетах для .NET Core O>Не попадалась ли нормальная документация где можно было бы увидеть таблицу что и где поддерживается ?
O>>>Есть ли где-то сводки что протестировано на разных платформах и работает +- одинаково, а что существенно отличается ? G>>https://dotnet.microsoft.com/platform/dotnet-standard O>Тут я нашел только очень краткую сводку, хотелось бы хотя бы детализация до сборока/класс. А в колонках платформы с флажками работает или частично работает/ совсем не работает.
Там все есть, надо много по ссылкам ходить.
Здравствуйте, okon, Вы писали:
O>Пихать больше в продуктовом смысле, пишут типа "мы в .NET Core включили" сразу ассоциации с кросплатформенностью потом бац "Winforms / WPF". O>мне кажется корректнее было бы в релизе .NET Core озвучивать только вещи которые кросплатформенны, и не включили WPF, а сделали WPF который может работать с .NET Core.
Если где-то так и написано, что «мы в .NET Core включили WinForms/WPF», это следует читать как «мы портировали WinForms/WPF на NET Core и включили эти библиотеки в комплект NET Core SDK для Windows».
Случайно использовать части WinForms/WPF в кросс-платформенном приложении вряд ли выйдет. Надо и соответствующие библиотеки в зависимостях подключить, и в C#-коде добавить namespace, в названии которого будет фигурировать слово Windows, что как бы намекает.
Поскольку WinForms ограничено поддерживается в Mono, библиотеки WinForms присутствуют даже в Unity, где они нафиг никому не нужны. Ничё, народ не путается. Просто не подключает их и не использует. Хотя при большом желании они даже могут работать.
Не знаю кто тут с чем не согласен, но у нас реально ситуация ровно такая. Дотнет без WinForms|WPF нахрен никому не уперся, это первый пункт который проверялся.
Серверный код можно на чем угодно писать. Если не добавлять WinForms|WPF проще все сразу на Angular|React|другую хрень переписывать.
Здравствуйте, rm822, Вы писали:
R>Не знаю кто тут с чем не согласен, но у нас реально ситуация ровно такая. Дотнет без WinForms|WPF нахрен никому не уперся, это первый пункт который проверялся. R>Серверный код можно на чем угодно писать. Если не добавлять WinForms|WPF проще все сразу на Angular|React|другую хрень переписывать.
Не надо говорить за всех.
А то окажется, что кто-то сидит в луже и думает, что он сидит в океане
Здравствуйте, okon, Вы писали:
НС>>Это довольно тяжело в вычислительном плане. Перемножение количества фреймворков и платформ даст такое количество комбинаций, что устанешь проверять.
O>Но я все же надеюсь что в MS перед выпуском фреймворка все API тестируют на платформах и у них есть чеклист что работает, что нет, а что впринципе не поддерживается ( код не написан ), как в случае WinForms например.
Щас для винды то обновления не тестируются. Вернее данный груз переложили на пользователей. Что уж тут хотеть для фреймворка
