VS2019, в чем разница, приложение WPF (.Net Framework) и App WPF (.NET Core)

Открыл сейчас VS2019, чтобы "создать новый проект" и не знаю на какую кнопочку нажать (я не программист, но потихоньку что-то делаю "для себя").
В VS2019 есть эти два стандартных шаблона для приложения WPF:
1. Windows Presentation Foundation - WPF (.Net Framework)
2. Windows Presentation Foundation - App WPF (.NET Core)
Тут сразу попутно вопрос. Почему одно называется просто WPF, а другое App WPF? В чем сакральный смысл такого различия в названии?

И главный вопрос.
Я не буду спрашивать "что лучше", ибо не хочу нарываться. Но если есть желание - высказывайтесь и в таком ключе, с интересом прочитаю и потом когда-нибудь пойму.
Я сформулирую вопрос так - Какие специфические проблемы я поимею, если выберу второй вариант - App WPF (.NET Core)?
И дополнительный вопрос - можно ли говорить, что будущее за App WPF (.NET Core) и что WPF (.Net Framework) постепенно уйдёт на фоне App WPF (.NET Core) в прошлое?
Ответы желательно дать в общем виде. Но если необходима конкретика, то скажу, что собираюсь сделать "для себя" приложение c# WPF десктоп, которое, возможно, будет содержать лёгкую СУБД (скорее всего SQLite) и которое будет взаимодействовать с некой стандартной клиентской программой (которая в свою очередь как-то там взаимодействует с удаленным сервером, но это уже не важно).
P.S.1. Слегка погуглил и просмотрел тему Что выбрать - WPF .Net Core или WPF .Net Framework + буду работать с SQLite (также интересно какую версию БД выбрать)?
P.S.2. Ответы в стиле - а ты типа начни с WPF (.Net Framework), а потом, если надо, легко перейдёшь на... - не приемлю. Некогда мне начинать с одного и прыгать потом на нечто другое. Мозги от этого опухают. Нужен один вариант.

P.S.3. Интуитивно склоняюсь к App WPF (.NET Core). Поскольку
- это относительно новое, типа новый шаг, а значит...
- это вроде лингвистически ближе к ASP.NET Core, до которого тоже хочется когда-нибудь доползти.

0

titan4ik, Что выбрать - WPF .Net Core или WPF .Net Framework + буду работать с SQLite (также интересно какую версию БД выбрать)?
Основные отличия...
Core разве что под линуксом можно использовать, если без UI.
Хотя, можно и с UI, если авалонию заюзать.

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

0

What is the future of .NET
https://www.c-sharpcorner.com/... f-dot-net/

Добавлено через 18 минут
Представлен .NET 5
https://habr.com/ru/company/ra... og/451136/

Добавлено через 8 минут
Мда, в контексте вышеизложенного (и прочего), похоже, что при всём богатстве выбора решение однозначно правильное будет такое: App WPF (.NET Core)

Добавлено через 10 минут
И до кучи местное обсуждение:
https://www.cyberforum.ru/net-... 48619.html

0

Сообщение от titan4ik я не программист, но потихоньку что-то делаю "для себя"

При таком раскладе не вижу смысла вообще заморачиваться и тыкать любую. Для целей "самореализации" обе будут решать 100% поставленных задач.

Такими вопросами должен задаваться профессионал, у которого стоит масштабная задача по созданию универсального кроссплатформенного решения с бюджетом, похожим на номера телефонов Вот только профи, скорее всего, и так знает, что ему выбрать и что лучше))

1

Сообщение от titan4ik В чем сакральный смысл такого различия в названии?

Возможно, внутри студия опирается на названия файлов шаблонов проектов, поэтому их надо было сделать различными.

1

Сообщение от titan4ik What is the future of .NET https://www.c-sharpcorner.com/... f-dot-net/

Ключевые особенности .NET 5 Ключевые особенности .NET 5 включают Единая унифицированная платформа для всего, включая Windows, Mac, Web, Mobile, Cloud, IoT, Gaming, Machine Learning и Data Science.

В реальности мало кому нужно.
В лучшем случае для 1% приложений.
Это больше из "Голубой мечты MS" откусить кусок пирога от других платформ.

Управляется сообществом открытого исходного кода и поддерживается Microsoft.

Да, это так. Но есть и свои минусы в этом. В целом особых преимуществ обычному (а тем более начинающему) это не даёт.
Играет роль для больших компаний, которые теперь могут направить развитие в нужную им сторону без одобрения (в теории) от MS.

Кроссплатформенность с любым устройством в любом месте.

Тоже самое, что с первым пунктом.

Поддерживает все основные возможности платформы для .NET Framework, .NET Core и Xamarin, включая Windows Forms, WPF, UWP, ASP.NET MVC, Entity Framework, LINQ и так далее.

Это неправда.
Это скорее декларация о намерениях, а не то что есть в реальности или то что будет.

Масштабируемая, быстрая и высокая производительность.

Первое - как уже писал, на практике почти ни кому не нужно.
Второе и третье - это правда. Но оборотной стороной является усложнение кодирования.

Меньшее развертывание и пакеты.

Разве, что по отношению к UWP.
Но UWP, по всем признакам, "приказала долго жить"...
По отношению к WPF+FW - это не верно.

Поддержка наиболее продуктивных IDE и инструментов, включая Visual Studio, VS Code, VS для Mac и интерфейс командной строки (CLI)

Это просто реклама от MS.
Большинство кто знаком с FW и Corу скажет, что очень многих привычных и широкоиспользуемых на FW инструментов нет на платформе Core.

0

Сообщение от titan4ik P.S.2. Ответы в стиле - а ты типа начни с WPF (.Net Framework), а потом, если надо, легко перейдёшь на... - не приемлю. Некогда мне начинать с одного и прыгать потом на нечто другое. Мозги от этого опухают. Нужен один вариант.

Вы же не будете без знания базовых основ C# лезть в сложные интерфейсы? В любом обучении и освоении идёт идёшь от простого к сложному.
Градация по "порогу вхождения":

• Консоль - начинающий. Получение базовых знаний C# и общих представлений об ООП.
• WinForms - требует уже понимания базовых основ C# и ООП. Предполагает изучение и освоение основных паттернов: MVC, MVP, MVVM. Начальное изучение механизма привязок. Позволяет писать приложения (в основном мелкие) в процедурном стиле (наверное, 90% приложений) - это же и является помехой для развития программистов. Без внешнего "толкателя" программист очень часто застревает на этом уровне и не может перейти к созданию более крупных приложений, научиться командной работе.
• WPF+FW - это специально созданный инструмент для реализации View в паттерне MVVM. Но возможно реализация приложений (только очень мелких, учебных) вне этого паттерна, хотя она и будет значительно сложнее MVVM реализации. Порог вхождения уже значительно выше чем на WinForms. Требуется хорошее знание C# и ООП, умение реализовывать паттерн MVVM, подготавливать контекст данных для привязок. Предполагает освоение второго языка XAML и всего связанного с ним: разметка, ресурсы, стили, шаблоны, триггера, анимации и т.д.
• UWP и WPF+Core - нацелены на многоплатформенность. Реализовать вне MVVM практически не возможно. Решает вопросы адаптации к различным платформам. Предполагается, что программист уже не задумываясь может воспользоваться всеми инструментами XAML, имеет примерное представление о "закулисье" XAML, умеет создавать свои контролы, настраиваемые элементы, с лёгкостью использует анимацию, корректирует дефолтные шаблоны (а они значительно сложнее чем на WPF+FW), умеет получать параметры системы и настраивать приложение под них.

0

Сообщение от titan4ik Мда, в контексте вышеизложенного (и прочего), похоже, что при всём богатстве выбора решение однозначно правильное будет такое: App WPF (.NET Core)

Если MS действительно откажется от FW, то переход на Core будет неизбежным.
Но надо понимать, что MS уже пробовала так сделать и у неё не вышло: лет пять (если не больше) они хотели всех перевести на UWP (Standart, вроде?). Но не вышло.
Нынешняя попытка (Core) тоже связана с желанием распространиться на другие платформы. Но очень сомнительно, что это выйдет.
А если не выйдет, то неизвестно и будущее Core.

Да, и сама себе MS противоречит. С одной стороны объявляет Core Open Source, с другой стороны расписывает на несколько лет вперёд план выхода версий....

Опять, таки не воспримите, что отговариваю вас. Это ваше дело за что браться. Просто предупреждаю, что WPF+Core значительно сложнее WPF+FW для неподготовленного программиста. В нём хватает своих проблем. И решать их не зная XAML, MVVM.... будет значительно сложнее.

0

Сообщение от Элд Хасп В любом обучении и освоении идёт идёшь от простого к сложному.

Правильно. Но путь от WPF (.Net Framework) к App WPF (.NET Core) не соответствует данному принципу. Это путь от старого проверенного продукта, о прекращении поддержки которого уже объявлено, к новому продукту, который должен заменить старый. Декларации это или так и будет - это вопрос открытый. Скорее всего истина посредине. Однако заявление о прекращении поддержки - это плохой стимул к освоению инструментария теми, кто не особо в него погряз.

Добавлено через 7 минут

Сообщение от Элд Хасп Опять, таки не воспримите, что отговариваю вас. Это ваше дело за что браться. Просто предупреждаю, что WPF+Core значительно сложнее WPF+FW для неподготовленного программиста. В нём хватает своих проблем.

Сложнее? Спасибо. Вот этого я даже не предполагал. Это странно как-то. Пока не понимаю как к этой информации относиться.

Сообщение от Элд Хасп В нём хватает своих проблем. И решать их не зная XAML, MVVM.... будет значительно сложнее.

Тут я не понял.
XAML он и в африке XAML. MVVM тоже - он и есть MVVM.
Неужели в App WPF (.NET Core) нет тех же основных библ классов (типов), которые используются в WPF (.Net Framework) для организации MVVM? Логично было бы, чтобы они были. И имели бы те же имена или отличающиеся стандартным образом. Или это не так?

Чем конкретно сложнее App WPF (.NET Core)?
Элд Хасп, неужели в нем нельзя использовать те ваши наработки, которые вы сделали в этой теме по патерну MVVM?

0

Сообщение от titan4ik Но путь от WPF (.Net Framework) к App WPF (.NET Core) не соответствует данному принципу.

Соответствует.
У Core (а это не обязательно WPF) есть своя специфика, которую надо осваивать помимо типа самого приложения: Консоль, WInForms, WPF.
И осваивать одновременно WPF и Core будет сложно.

Опять таки вам самому решать, это просто совет по моему собственному опыту - хотите прислушайтесь, не хотите - нет.
Я бы советовал не осваивать одновременно две новые (для вас) технологии.
Осваивая WPF вы по любому будете обращаться за советами.
А посмотрите по разделу.
Вопросы по UWP - практически без детальных ответов.
То же самое будет и по WPF+Core, поскольку шаблоны UI элементов значительно различаются.
Реальные приложения WPF - 99% на платформе FW.
Самостоятельно же освоить с нуля с собственными силами XAML и MVVM будет чрезвычайно сложно.
В результате вы останетесь один на один со своими проблемами и даже не будете понимать в чём их причина: неправильное использование платформы Core, ошибки в XAML или неверно построенный MVVM.
Если уверены в своих силах, что же - "Вперёд и с песней!".

Добавлено через 5 минут

Сообщение от titan4ik Неужели в App WPF (.NET Core) нет тех же основных библ классов (типов), которые используются в WPF (.Net Framework) для организации MVVM?

Да.
Многих типов нету.
Даже реализация команд (а это основной способ вызова методов ViewModel) совершена различна, поскольку в Core нет CommandManager.
И следить за обновлением состояния команд надо "вручную".
А это сложно.
Поэтому начинающие просто "забивают" на это. Сами по себе команды начинающим понять не просто, а тут надо ещё и вручную их обновлять - "Ну их к чёрту!".
В результате получается костыльный код с полумёртвыми командами.

Это то что с ходу вспомнилось, а таких нюансов и проблем очень много.

Добавлено через 6 минут

Сообщение от titan4ik XAML он и в африке XAML.

Не спорю.
Но шаблоны элементов на FW много проще.
И на них намного проще научиться их корректировать или составлять самому.
Так же надо понимать, что XAML - это декларативный язык и он не "Сферический конь в вакууме".
Он использует те типы которые предоставляет платформа, а многих типов FW в Core нет.
И то что в FW вы можете описать пятью строками XAML, в Core может потребовать страницы кода XAML и сопутствующей ей страницы кода на C#.
А вы ещё даже не освоили XAML, как вы собираетесь своими силами писать нужные для неё типы?
Это сложно даже не начинающему.

0

Сообщение от Элд Хасп У Core (а это не обязательно WPF) есть своя специфика, которую надо осваивать помимо типа самого приложения: Консоль, WInForms, WPF.

А причем тут вообще WInForms? Зачем мне нужно изучать этот старый уходящий инструментарий, если у меня цель создание WPF приложения на платформе .NET Core.?

Сообщение от Элд Хасп У Core (а это не обязательно WPF)

Да, я не правильные термины в последнем сообщении использовал. Имел ввиду конечно альтенативу .NET Framework или .NET Core.
Но в моем конкретном случае это выражалось в выборе типа шаблона в VS2019 - WPF (.Net Framework) или App WPF (.NET Core).
Но смысл разумеется в выборе платформы.

Сообщение от Элд Хасп осваивать одновременно WPF и Core будет сложно.

Не понял.
Известно некоторое количество хороших букварей по WPF. То, что там написано не применимо в случае использовнаия платформы .NET Core.?
Если не применимо, то есть ли аналогичные для WPF на основе .NET Core.?

Сообщение от Элд Хасп Вопросы по UWP - практически без детальных ответов. То же самое будет и по WPF+Core, поскольку шаблоны UI элементов значительно различаются.

То есть, вы полагаете, что идти сейчас в сторону .NET Core. без хорошего опыта работы на базе .NET Framework это значит бежать впереди паровоза, не имея даже корочки младшего помощника машиниста?
То есть для этого шага нет достаточной инфраструктуры (учебники, материалы в инете, сообщество для поддержки ответами на вопросы)? Правильно?

0

Сообщение от titan4ik неужели в нем нельзя использовать те ваши наработки, которые вы сделали в этой теме по патерну MVVM?

Конечно, возможно.
Но научиться этому на Core было бы намного сложнее.
Даже сейчас мне не просто переходить на Core.
Не потому, что привык к FW, а потому что для написания эквивалента на Core надо многие типы писать самому, надо уметь правильно работать с системой (которая не обязательно Windows DeskTop).
То есть создать приложение WPF+Core я могу, но это требует намного больше усилий и кода чем для FW.
Поэтому без необходимости я WPF+Core не создаю.

1

Сообщение от Элд Хасп Но надо понимать, что MS уже пробовала так сделать и у неё не вышло: лет пять (если не больше) они хотели всех перевести на UWP (Standart, вроде?). Но не вышло.

Сравнивать UWP и .NET Core некоректно на мой взгляд. Первая это платформа для GUI приложений, вторая платфома для всех приложений. Массовый переход на UWP не состоялся потому что требовал изучения совершенно нового подхода без видимых преимуществ перед старыми, из-за архитектурных ограничений заложенных в UWP, из-за привзяки к Windows App Store, из-за просто плохой реализации. .NET Core с другой стороны будучи обратно совместиой с .NET FW расширяет и улучшает его. И в силу своей кроссплатформенности так и просится в качестве замены чтобы не было необходимости сопровождать .NET FW, Mono (Xamarin) и .NET Core. Проще иметь один фундамент для всех. Именно поэтому переход на Core логичен и неизбежен.

Сообщение от Элд Хасп Нынешняя попытка (Core) тоже связана с желанием распространиться на другие платформы. Но очень сомнительно, что это выйдет. А если не выйдет, то неизвестно и будущее Core.

Учитивая уже существующие инновации в .NET Core (взять хотя бы JIT и AOT) её в любом случае ждет хорошее будущее независимо от успеха на других платформах.

Сообщение от Элд Хасп Да, и сама себе MS противоречит. С одной стороны объявляет Core Open Source, с другой стороны расписывает на несколько лет вперёд план выхода версий....

В чем тут противоречие?

3

Сообщение от titan4ik А причем тут вообще WInForms? Зачем мне нужно изучать этот старый уходящий инструментарий, если у меня цель создание WPF приложения на платформе .NET Core.?

Я просто пытаюсь вам объяснить, что суть Core - это не WPF.
Это другая платформа значительно отличающаяся от FrameWork.
А интерфейс пользователя может быть любой: Консоль, WinForms, WPF, UWP. Навероне, и ещё какие-то есть.

Добавлено через 1 минуту

Сообщение от titan4ik То есть для этого шага нет достаточной инфраструктуры (учебники, материалы в инете, сообщество для поддержки ответами на вопросы)? Правильно?

Да. Так и есть.

0

Сообщение от Элд Хасп Так же надо понимать, что XAML - это декларативный язык и он не "Сферический конь в вакууме". Он использует те типы которые предоставляет платформа, а многих типов FW в Core нет. И то что в FW вы можете описать пятью строками XAML, в Core может потребовать страницы кода XAML и сопутствующей ей страницы кода на C#. А вы ещё даже не освоили XAML, как вы собираетесь своими силами писать нужные для неё типы? Это сложно даже не начинающему.

Не понятно в таком случае почему MS считает .NET Core. следующим шагом вперед, то бишь более прогрессивной альтернативой .Net Framework. Складывается такое впечатление, что это продукт с несколько иным предназначением - даёт больше возможностей, но при этом одновременно требует большей ручной работы.
Не понятно. Неужели рептилоиды проникли и в MS? Вредители?!
Элд Хасп,
спасибо за ваши предостережения. Я не вполне согласен с некоторыми вашими аргументами. Но в целом вы зародили во мне вполне конструктивное сомнение.
Хорошо, что вчера я так и не нажал на эту кнопку. А то бы мог влипнуть всерьез и надолго!

0

Сообщение от titan4ik Известно некоторое количество хороших букварей по WPF. То, что там написано не применимо в случае использовнаия платформы .NET Core.?

Многое, что из "букварей по WPF" на Core работать не будет.

Добавлено через 9 минут

Сообщение от OwenGlendower Сравнивать UWP и .NET Core некоректно на мой взгляд.

В данном случае, я только приводил пример, что не все надежды MS осуществляются.
Я не сравнивал платформы между собой.

Сообщение от OwenGlendower Учитивая уже существующие инновации в .NET Core (взять хотя бы JIT и AOT) её в любом случае ждет хорошее будущее независимо от успеха на других платформах.

Опять таки сколько было от MS "хороших инноваций", о которых сейчас все забыли?

Сообщение от OwenGlendower В чем тут противоречие?

Если это Open Source, то, на мой взгляд, трудно строить далеко идущие детальные планы.

Сообщение от OwenGlendower .NET Core с другой стороны будучи обратно совместиой с .NET FW расширяет и улучшает его.

Это не так.
Попробуйте запустить FW на Core или наоборот.
Тот же MessageBox широко используемый на FW - его нет в Core. Или FileOpenDialog.
WPF конвертеры требуют другой сигнатуры.
Нет CommandManager для команд.
И ещё много других отличий, которые в принципе не будут ликвидироваться.

Добавлено через 3 минуты

Сообщение от titan4ik Не понятно в таком случае почему MS считает .NET Core. следующим шагом вперед, то бишь более прогрессивной альтернативой .Net Framework.

Core уже шаг вперёд по той причине, что есть открытые исходные коды.
Можно посмотреть как реализуется тот или иной тип.
И, соответственно, реализовать свой по подобию.
Я именно таким образом сейчас и разбираюсь с AP-свойствами списочного типа: Освоение Attached Properties: Списочное свойство

Но в данный момент, освоение Core сложнее чем FW. Возможно в будущем это будет не так.

Добавлено через 1 минуту

Сообщение от titan4ik Складывается такое впечатление, что это продукт с несколько иным предназначением - даёт больше возможностей, но при этом одновременно требует большей ручной работы.

Не только больше "ручной работы", но и большего понимания взаимодействи платформы с системой и UI интерфейсом.

Добавлено через 3 минуты

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

Почему же - нажмите.
Я тоже нажимал.
И делал простые примеры на разных платформах.
Когда уже сложность "борьбы" с платформой превысила сложность реализуемых задач, то перешёл в основном на FW.
Но при необходимости, могу сделать что-то и на Core.
Но на то, что мне требуется день в FW на Core может уйти 3-5 дней.

0

Сообщение от Элд Хасп И ещё много других отличий, которые в принципе не будут ликвидироваться.

А не может быть так, что в MS решили, что в прошлом были допущены некоторые ошибки. И в новой платформе они их просто устранили? Ибо - не тащить же кривое прошлое в светлое будущее.
Я читал про функционал команд (не оч много) в WPF (.NET Framework) и у меня осталось скверное ощущение от этой части. Такое впечатление (некомпетентное), что всё могло бы проще реализовано. Но я в этом далеко не эксперт. Однако, "чуйка" меня по жизни редко подводила.
Вообще такое ощущение, что идеи технологий настолько опережают технологии, что сами технологии до ума довести не успевают (ни на этапе разработки концепции, ни на этапе реализации).
К тому же всегда есть противоречие между простотой использования (в том числе - порогом вхождения) и возможностями тонких ручных настроек - попытка найти оптимальный компромисс может порождать монстров. Не исключаю, что именно этим MS и занимается. А учитываю их финансовые возможности, они могут далеко увести нас всех в сторону от столбовой дороги в ясное светлое будущее. Но альтернативы нет - приходится плестись у них в хвосте, да ещё и благодарно кланяться за вдыхаемую высокотехнологичную пыль.
Мда. Кто виноват понятно. Но что же делать?!)

0

Сообщение от titan4ik А не может быть так, что в MS решили, что в прошлом были допущены некоторые ошибки.

Не сколько ошибки, а сколько привязка к Windows Desktop.
Все типы которые к ней привязаны, в Core, в принципе, реализованы не будут.
Даже работа с файловой системой в FW и Core различается.

1

0

Сообщение от titan4ik Я читал про функционал команд (не оч много) в WPF (.NET Framework) и у меня осталось скверное ощущение от этой части. Такое впечатление (некомпетентное), что всё могло бы проще реализовано. Но я в этом далеко не эксперт. Однако, "чуйка" меня по жизни редко подводила.

Я когда с командами разбирался, мне тоже так казалось.
Поэтому несколько раз делал свои типы заменяющие ICommand, но в результате получалось только ещё хуже или сложнее.

Основная причина в Привязках. Это основной (можно даже сказать - единственный) способ связи XAML с ViewModel.
А привязку возможно создать только к свойству.
Поэтому передать управление непосредственно методу не получится.
Так же очень частая потребность для View знать когда метод может быть выполнен, а когда нет.
Отсюда появляется потребность во втором методе и в событии уведомляющем о состоянии команды.
Как не крути выходит три члена интерфейса.
Проще не получается - я уже много разных вариантов перепробывал.

1