Если ли смысл уходить с C++\Qt в C#+WPF?

Добрый день ! Так сложилось что я пишу под десктоп и делаю я это хорошо, более того мне такая работа очень нравится, в основном это С++ и Qt, но мне предложили работу в Харькове (я сам из Запорожья), на стеке .NET и именно : C#\WPF и очень хорошую оплату труда, дают месяц на подготовку, но ответ нужно дать до конца месяца.

И я вот думаю стоит ли оно того, я уже как-бы привык к С++, но работы по Qt всё меньше и меньше, денег тоже платят меньше чем мне предложили, может это правильный вариант перескочить на WPF, работы видать больше если хотят людей из С++ перетащить ? Буду рад общению.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

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

позиции С диез сейчас шатки

— Нет, нет, всё очень хорошо ! Xamarin хорошенько на рынок вылез, ASP Core набирает популярность, я вообще работаю на UWP который мало кому известен, на гребанном Unity пишут аж клавиатуры горят и вообще мир ещё не придумал ЯП со статической типизацией лучше чем C#, разве что Котлин может быть не плох, а так «Шарп» — это лучшее с чем можно работать !

Xamarin хорошенько на рынок вылез

Все ж злетів він?

Он уже занял свою (пусть не большую) нишу и знаю конторы которые только и занимаются кросплатформом на Xamarin и бек-ом на ASP.NET для этих моб.приложух в итоге они используют «Шарп» для всех проектов и очень счастливы ...
— Когда я работал с Xamarin, то могу сказать что по большому счету кросплатформ не так страшен, если в большинстве случаев нужно заюзать API, а клиент ты пишешь на Xamarin без особой сложности ...

Часто доводилося мати справу з API Android, iOS?

Приходится конечно. Я скажу так, если хочется работать с Xamarin и вообще этим заниматься (что бы не было проблем) то просто обязательно знать как устроен Android\iOS понимать Java\Obj-C, лучше вообще поработать пол года нейтив-разработчиком на обеих платформах, потому что лезть в каждую платформу и смотреть чё там такое, прийдется часто, на первых порах это напрягает, а потом привыкаешь и педалишь нефиг делать ...

Я тебе так скажу, это абсолютно очевидно, что будет так же как с джаваскриптом, хтмл и браузерами в начала 2000-х. Сначала приходилось писать куски ветками под каждый из браузер, потом плюс-минус все стандартизировалось, адаптация новых фич идет с заддержкой максимум полгода-год.
Так и мобильные будут писаться на одном и том же языке, react-native только первая ласточка.

Это вы хотите сказать что ужасный JS вытеснить нейтив и Xamarin с помощью RN и захватит мир ?
Тогда я уйду в подпольное сопротивление и нашей миссией будет ликвидировать Брендана Эйха !

Я хочу сказать, что не все, но большую часть приложений можно написать уже сегодня без нейтива. И с точки зрения бизнеса очень выгодно иметь на 90% шареннный код между вебом, айосью и андроидом без необходимости повторять одно и то же на трёх платформах и в большинстве случаев разными командами из-за разных компетенций. И именно туда пойдёт движение в развитии подходов для написания мобильных приложений.

И с точки зрения бизнеса

Я вас понимаю, но с точки зрения здравого смысла JavaScript лучше никогда не использовать вообще нигде !

Использование JavaScript растет самыми высокими темпами среди языков последние лет 5 точно. Вы хотите сказать, что только вы обладаете здравым смыслом, а все остальные идиоты?

JavaScript растет самыми высокими темпами

— Растет потому что альтернативы нет, по этому люди рыдают но пишут на нем ...
И за это время адекватные люди много раз пытались от него уйти выдумывая всякие TypeScript, CoffeeScript и им подобные ...

Использование JavaScript растет самыми высокими темпами среди языков последние лет 5 точно. Вы хотите сказать, что только вы обладаете здравым смыслом, а все остальные идиоты?

Рост с 1 полъзователя до 30 пользователей — это да, очень высокий темп. В 30 раз!

Кто с таким темпом может сравниться? :)

ужасный JS вытеснить нейтив и Xamarin с помощью RN

в этом случае нужно будет ликвидировать не Эйха, а Цукерберга (типа. многоходовочка «ликвидируешь Цекерберга -> загибается фейсьбук -> реакт некому разрабьатывать -> загибается React Native -> загибается даваскрипт на мобилках». Как то так). :)

В первую очередь ты для себя реши нужно оно тебе или нет, интересно тебе туда переходить или не интересно, хочешь ты или нет. Потому что сейчас каждый насоветует со своей точки зрения, но «ты» же не «оние»? Никто ж не знает какие у тебя тараканы в голове и чем тебе интересно упарываться. Поэтому если вопрос стоит из разряда «насколько перспективно в ближайшие годы заниматься А или Б», то мой ответ: что одно, что другое будет еще не один год востребовано при условии, что ты хороший специалист в этом направлении.

Переходить однозначно стоит. Во-первых — С# позволяет сосредоточиться на том, что именно ты хочешь сделать, а не на том, «как сделать, то, что ты хочешь сделать». Управление памятью, ресурсами, интеграция с различными сторонним сервисами — все это на порядок проще и изящнее делается в C#. Во-вторых, .NET очень большая платформа и постепенно можно мигрировать в другие направления — веб-разработка, мобильная разработка, разработка клауд-сервисов, разработка высоконагруженных систем и так далее. При этом не нужно будет каждый раз все учить заново — базовые навыки и знания будут «переиспользовать» в любом направлении. Я уже не говорю о том, что рефакторинг и поддержка кода на C# гораздо проще и приятнее, чем в С++.

ИМХО: Я считаю что Qt лучше чем WPF потому что:
1) Кросплатформ !
2) Можно даже под мобильник зафигачить !
3) Производительность ощутимо выше в Qt !

1 и 2 — а надо ли? При наличии React Native, Xamarin, Phonegap, Electron, etc люди в последнюю очередь посмотрят в сторону Qt
3 — оочень спорный момент, ибо скорее всего вы просто не умеете WPF готовить

Уважаемый Ebanat, не знаю что сказать просто хотел к вам обратится по фамилии...

ну так скажите что хотели, к чему медлить?

Я свои пару слов вставлю. Мы делали всё на WPF. Расчеты производились прям на компах людей. Расчеты были всё сложней и компы висли. Мы перенесли всё на сервер с доступом через SOA (WCF). Слишком много гемора как с WPF, так и SOA. Сейчас маленькие веб-сервисы работают как ASP.NET 5(пока не Core, слишком нестабилен еще) которые крутятся на IIS. Большие сервисы — это службы Windows, с ASP.NET+Owin+Планировщик Hangfire. Морду теперь пишем на Angular 5 и не паримся. Теперь жизнь проста...

Но так же стоит сказать что есть большое количество ПО которое просто невозможно засунуть в ВЕБ и оно будут жить под десктоп до скончания века, а это подразумевает что хоть WPF или Qt будут жить и здравствовать, правда потребность в них будет не в том количестве что было 10 лет назад ...

Wpf не плох но (хоть и оценил styles, MVVM).... Вынужден был юзать под Charts WindowsFormsHost ибо компоненты по рисованию графиков для Wpf просто унылое и тормозное г... Отсутствует куча контролов типа NumericUpDown и тому подобное. Пилить всё это под свои потребности с нуля — да упаси бог (нет столько времени). Как итог вынужден был снести статические стили ибо WindowsFormsHost не отображает контент (при Setter Property="AllowsTransparency" Value="true«), а в false расползаются стили и для каждого UserControl приходится пилить свой динамический (Я конечно ещё джун откровенный в ООП. Только 7 месяцев как с 1С слез почти слез альт+табаюсь между %) ). Короче не всё хорошо на C# WPF. Сейчас вот собираюсь сносить стиль главной формы где в border к мин/макс/закрыть докинул свою кнопку «?» о программе ибо из-за AllowsTransparency=faslse и ResizeMode="CanResizeWithGrip" над моим тайтлбаром не убираемая полоса. Как итог запилю ещё одну кнопку в меню «о программе». Короче красиво, быстро и удобно в разработке на C# WPF что-то не очень получается. А заявления майкрософта о том, что: пилите контролы себе сами(утрирую)... ну ёбаба давайте тогда с ассемблера каждый начинать сначала биос накидать затем ос потом среду разработки потом контролы и потом будет счастье... Сорян накипело!

Так зачем изобретать велосипед? Используй библиотеки telerik или devexpress и будет тебе счастье

Devexpress 900$ с ипотекой не могу пока себе такие траты позволить

Ну если контора на либы не хочет тратиться, то да, пили контролы вручную

Контора не совсем по этой области. Короче производим химоту под нефтянку — потребовался софт для упрощения расчетов группы профессуры, которая лаборатории напрягает и строит теоретическую модель. Я написал используя всё что под руку попадётся. Сейчас эту прогу ставят на баланс предприятия + заинтересовался народ из различных нефтяных компаний. У руководства возникла идея что софт нужен (ибо на рынке подобного софта нет при проверке теоретических расчётов на экспериментальной скважине получили 1.5% плюсом к добываемой нефти )... Как утрясут состав рабочей группы и размер финансирования, буду выбивать деньги на компоненты и на шезлонг на берегу моря. Но пока меня бомбит :)

Так и наваяй им на коленке контролов, а потом так невзначай — вот если бы был у меня devexpress, то я бы вам такое запилил бы...

Так так и будет. хотите вкусняшек дайте бабла! Просто в этой компании все долго решается и согласуется... точнее не так ОЧЕНЬ ДОЛГО... ООООООЧЕНЬ ДООООЛГО. Я за это время успел подучить C# и свалить с WinForm на WPF и отдизайнить и вылизать прогу. Осталось впихнуть последний график и формочку «О программе» и всё...

А что мешало нормально вынести расчеты на сервер и продолжить клиентскую сторону на WPF, а не писать клиента с нуля? Или вам очень пригорало уйти от WPF’a в сторону веба?

Когда я с коллегами «сваливал» с гейм-дев’а то одни ушли в Xamarin, другие в WPF (и в wpf больше народа пошло что странно). У же как год прошел и все довольны, работа есть и тут и там, нормальные зп, никто не плачится что WPF здох или Xamarin не взлетел, хотя вакансий даже если взять WPF и Xamarin вместе все равно не перебьют количество которое есть под ASP.NET. Тут дело в желании, если сильно хочется то и на cobol’e работу найти можно ...

Как вспомню свой первый релиз на WPF, это было ужасно, тормозило дико — layout умирал в листе под чистую (решалось дикими извращениями). Мемори-лики лезли без остановки — хорошо что есть / был ntsd c sos.
С тех пор и железо стало быстрее, да и WPF с .Net лучше стал. Кстати человеку, который выкосил ntsd из Windows — яйца стоило бы отрезать.

WPF прикольная штука и достойна ознакомления / изучения. Qt то же интересна библиотека достойная внимания.

Выбирай не по технологиям — а по интересности работы и условиям!

Вопрос хорош и стоит отдельного обсуждения но совершенно не в том ключе в каком поставлен в том же ж ключе в каком поставлен формулировка «уходить» вообще неясна есть работа есть возможность её выполнить как именно при этом понимается слово «уходить» сам процесс полагает подписание формального отказа работать с «прошлой» технологией/стеком на ближайшие ххх лет? «прошлая» технология/стек полагается быть сразу забытой и процесс возврата снова к её использованию полагается крайне дорогостоящим? в чём именно выражается слово «уходить» в данном контексте?

Уважаемый мной лично тов. Шлее автор хорошей книги по QT на русском языке выпускает уже (пришлось обратиться к картотеке издания) уже 5-ю книгу в целом про одно и то же ж и в целом даже одинаковую (по отзывам осведомлённых товарищей на основании изучения содержания последних 2-х) :

— Qt. Профессиональное программирование на C++
— Qt4. Профессиональное программирование на C++
— Qt4.5. Профессиональное программирование на C++
— Qt4.8. Профессиональное программирование на C++
— Qt5.3. Профессиональное программирование на C++

— это с 2006-го года по 2015-й почти 10 лет конечно за это время и сам (сама?) QT изменился но не настолько чтобы «настольная книга как войти в qt» претерпела значительные изменения есть все основания полагать что в ближайших 1-2 года сколько там полагается длиться проект «на другой технологии» существенных изменений потребовавших бы б изучение всего материала «с нуля» не наступит ни в самом QT ни в C++.

Итого «спор дискуссия» идёт вовсе не в том ключе «смысл уходить» потому как никакого «уходить» и нет видимо реальная дискуссия так или иначе ведётся примерно в вопросах «жива ли технология» «следует ли начинать новый проект на такой технологии» «следует ли вкладывать в изучение технологии» и т.п. но эти все вопросы лежат полностью _все_ поставленного «смысл уходить» потому как никакого «уходить» и нет.

денег тоже платят меньше чем мне предложили

Ты их не слушай ты меня слушай я тебе совершенно лично обещаю никуда «уходить» не придётся и как только предложат снова QT сразу же ж сможешь «вернуться» более того в чистом профите «а я тут изучил также другие аналогичные технологии и имею опыт сказать...»

ПрофитЪ!

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

Если вам она не нравится или вы ее не используете, то это не делает ее мертвой. Это раз. .NET, нравится вам это или нет, один из наиболее используемых универсальных (почти) технологических стеков, а то дает достаточно большое разнообразие в выборе что делать.

ну WPF уже правда не очень жив. Теперь же UWP везде

Живее всех живых :). Просто не так популярен ибо desktop, а не web. Про UWP не берусь судить. На мой взгляд, как здесь больше вопросов, чем ответов.

мертв? Прога для 3D моделинга Autodesk 3D Studio Max 2017 написана на WPF...

«%ttile% мертвая технология» — я это уже 15 лет только и слышу, вон ASP.Net начинали хоронить еще на заре 2000-х =))

Если сравнивать гуи фреймворки WPF vs Qt, то имхо последний побеждает как более перспективный: активно развивается QML, кроссплатформенный, охватывает не только десктоп, а и мобильные тоже. Но сравнивая C# и C++, очевидно преимущество первого и по удобству, и по количеству вакансий. Если переходить с прицелом перескочить с WPF на Веб, то стоит. Но если нравится именно десктоп, то хз что лучше из этих двух вариантов, да и вообще десктопных приложений в принципе уже мало, все больше веб и мобилочки.

Выглядит это так, что на десктопном клиенте C++ уже мёртв.

Переходить. Как уже написали, сперва на WPF, а потом на веб (а еще лучше ASP.NET Core). Вакансий по .NET гораздо больше, а ЗП уже догоняют Джавовские.

Опять таки, больше вакансий. Silverlight, WPF — это все проходящее, веб — вечен :)

проходящему WPF уже больше 10 лет, и на нём продолжают активно педалить морды крупных проектов.
Silverlight — да, как-то не прижился.

Вас не бентежіть те, що від ASP.NET залишилися лише Web API проекти? Більшість зараз — це SPA. Існують рішення і що до кращого SEO, і ентерпрайз їх впроваджує. А враховуючі GraphQL від бекенду мало що залишається для переважної більшості випадків.
Топікстартеру можу порадити подивитися на Rust. Хайпу багато, мабудь, цікава річ. Перейти в C# - це як релігію змінити ))) Це як вмовляти себе продовжувати пилякати на ado.net, запокоюючи себе, що «повний контроль» на відміну від «попсового» EF. Може, він до такого не готовий -)

А враховуючі GraphQL від бекенду мало що залишається для переважної більшості випадків.

очередная, к тому же далеко не первая в своем роде технология, просто более раскрученная чем предшественники. еще до GraphQL существовали расширения для REST, которые позволяли писать запросы в базу используя js. На необходимость написания бекенда систем это мало влияет — для каких-то задач просто упрощает работу с ним.

Совершенно верно. Но с учетом того, что половина работы в таких бекенд проектах заключена в boilerplates с dto и linq, то это сильно упрощает жизнь. Особенно хорошо то, что значительно сокращается время ожидания «нового эндпойнта», который нужно было добавить, накопипастить кучу кода, написать тесты. А нам все это время приходилось довольствоваться фейковыми данными.

Первый раз слышу что graphql поможет надизайнить доменную модель и сгенерировать Seed. Не совсем понял про boilerplates — graphql это и есть Linq (http запрос в него раскладывается) только написанный на фронтенде. Бизнес логика остаётся попрежнему на бекенде, фронтенд контролирует какие ему можно данные получить — в каком объёме с каким условием и каком виде, так же не понимаю как это избавляет от необходимости покрывать что-то тестами, кроме трансляции http запроса в Linq, что тестируется редко в бизнес логике. На фронт енде на это также надо время тратить — это просто библиотека с набором стандартных функций и решений. Что бы было понятней приведу другую параллель — за последние 10 лет на фронтенде появился underscore, two-way binding, CSS transitions , materials и тому подобное и почему-то фронтедщикам все равно есть что делать.

Про «доменную модель» — это Вы додумали. Я писал про DTO и про ендпойнты с различными представлениями entity из модели. Если у Вас все запросы возвращают чистые списки, которые Вы потом препарируете на клиенте, это не значит, что это оптимальный вариант.

Ну а что вы можете сделать с graphql готовя данные на фронт енде? Эффективно — сделать обьекты-проекции — убрать какие-то поля из результата или дать им алиасы, применить пейджинг, отфильтровать что-то, отсортировать.
Группировку c graphql сделать нельзя, операции с множетсвами отсуствуют, join выливается в лютый костыль под красивым названием batching, когда надо fetchить коллекцию id, а потом вторым запросом по коллекции id fetchить относящуюся коллекцию данных и смерджить ее на том же фронт енде(только это делает js либа). Вы всерьез думаете, что такие прогрессивные подходы это лучше чем ’bolierplates с dto и linq’?

graphql-agregate делает это на этапе проектирования типов. И опять же фронтендер в состоянии это сделать сам, не дожидаясь «серьезных парней с бекенда».
Возвращаясь к проблемам топикстартера, можно было бы согласиться, что специфики вэба в проектах C#/.Net практически не остается. Все вырождается в сервисы (которые постепенно вырождаются в набор правил валидации). Поэтому, когда говорят, что, мол, альтернатива десктопу — веб, я говорю, что альтернатива — черные коробки сервисов. Либо работаешь с кнопочками, либо с абстрактными данными.

сервисы (которые постепенно вырождаются в набор правил валидации)

А бизнес логика куда девается при этом?

SPA

Ага, уже года 3 слышу сказки-страшилки о том, что везде сплошные SPA. Только вот почему-то на какой новый проект не глянешь — везде клиенты пишут на server-side MVC фреймворке.

Это-таки не «сказки-страшилки», даже кроваво-энтерпрайзный SharePoint уверенно движется в этом направлении.

Другое дело, что для каких-то задач наличие SPA не критично, а имеющиеся заготовки на server-side MVC позволят решить задачу дёшево и эффективно.

Вас не бентежіть те, що від ASP.NET залишилися лише Web API проекти?

Это как раз таки чудесно, что фронтендовая часть полностью отделилась от серверной. Это позволяет куда эффективнее реализовать каждую из частей системы, сосредоточившись на бэкенде на архитектурных вопросах, вопросах нагрузки, обработки данных и бизнес-логики. А некритичный UI можно отдать команде фронтенд разработки, которая может вообще быть не в курсе, что и как там работает внутри, а только знать спецификацию REST API системы.

Переходи. В странах запада херова куча решений на C#/WPF — от гуёв для трейдинговых систем, до клиентских мест к томографам.

К тому же, чем больше технологий в cv (только с серьёзными проектами) — тем лучше. Бывает, люди даже на заниженный рейт соглашаются, если есть возможность поработать на проекте с чем-то (для людей) новым.

По-моему глобально это один и тот же стек. Ну сделаешь шаг в сторону, если хорошие бабки, то почему нет?

Переходите на веб (ASP.NET MVC, Web API). Или на WPF, а потом на веб. Сам прошел такой путь и могу сказать, что веб-фреймворки от MS очень легки в работе, особенно после десктопа. Например, когда я писал под WPF, то очень хорошо знал многопоточность (TPL, диспатчеры, async/await, мютексы, волатайлы с интерлоками и т.д.) и активно применял её на практике. При написании под веб не примомню случая, когда задача не решалась бы использованием async/await. Это всё в основном из-за модели многопоточности веб-сервера, когда есть только асинхронные операции ввода/вывода, а самому запускать какие-нибудь таски уже нельзя. Отсюда и меньше проблем.
Не скажу, что это хорошо, т.к. «теряешь форму», но в принципе, если работать только под веб, этого будет достаточно.

этого будет достаточно если вы делаете простые сайты и вся логика веб сервера ложиться на паттерн — получить запрос\прочитать базу\вернуть ответ. В остальном если на веб сервере есть CPU intensive вычесление\веб-сокеты\обмен событиями через messaging с другими системами и тому подобное надо много чего знать про многопоточное и асинхронное программирование и его особенности в .NET — в частности еще и потому, что в System.Web оно сделано пожалуй наиболее косячным образом из всех существующих популярных фреймворков на других языках и технология аналогичных c#/.NET, не в последнюю очередь благодаря тому, что делалось 15 лет назад когда требования к веб-системам были совсем другими.
Asyn/Await — инструмент для асинхронного, а не конкурентного программирования.

Да, я согласен.
Кстати,

если на веб сервере есть CPU intensive вычесление

 — а вы такое не перенесли бы в облако? Скажем, на какие-нибудь веб-воркеры в Azure?

может и перенес бы, зависит от контекста задачи ведь и технологий решения в целом. Если вопрос касаеться того стоит ли использовать веб сервер для того, что бы активно нагружать процессор, однозначного ответа нет — зависит от сложности вычислений, предпочтительного способа масштабирования, SLA, целесообразности усложнения системы из расчета времени и других подобных вещей. В целом для более менее стандартного решения, когда есть клиент\сервер\пару источников данных и даже незначительная необходимость что-то посчитать или обработать какие-то данные во время чтения, то предпочтительней оставить эту логику на стороне сервера и посчитать в одном потоке прочитав если надо параралельно данные из источника простыми запросами — если уже совсем очевидно, что можно получить выиграшь распаралелив что-то, в .net есть масса отличных высокоуровневых инструментов, которые избавляют от необходимости заниматься низкоуровневой синхронизацией и позволяют контролировать как и где эти вычесления будут проводится без надобности запускать потоки или даже делать простой и многими любимый Task.Run т.к. это не очень все удобно\эффективно, а чаще всего вообще выглядит как псевдоасинхронные вычесления когда повсеместно используеться async/await.

тут у наших коллег совершенно другое мнение:

dou.ua/forums/topic/21246

Я пытался их переубедить, но меня не поняли. Может они и вас переубедят.

Ну а прыгать в шарп я не советую, там положение еще херовее! Сегодня та компания существует, а завтра ее не будет. Опять переучиваться?

ЗЫ. Я сам из Запорожья

При всём уважении к вам и вашему опыту смею вам возразить ! Это почему же положение на «Шарпе ХЕРОВИЕ» ? Шарп офигенен и работа есть в разных областях (GameDev, WEB, Mobile), я из Днепра но могу приехать к вам в Запорожье и за бутылкой «хеннесси» поговорать что Шарп далеко не херовие ваших «плюсов» !!!

Только в этом месяце было пару постов — если там будущее и куда спрыгнуть. Советую им присмотреться на УВП, радости у них это не вызвало. Я пробовал перевести прогу на УВП, но не подошло, там у них если прога в бекграунд уходит, винда ее снимает. А у меня на этом все, как раз и построено.
А посидеть за коньячком только за!

Вот как-раз на UWP работы таки мало, я бы сказал архи-мало по отношению к тому же умирающему WPF, конечно в будущем может всё поменяется но мне чего-то так не кажется, ох как печально сейчас выглядит UWP ...

А посидеть за коньячком только за!

Как буду в Запорожье на выходных напишу вам, с меня элитное бухло !

к тому же умирающему WPF

Вендекапец вон тоже обещают чуть ли не с 90х годов, а он всё никак :)
Для корпоративных решений WPF + ClickOnce может быть прекрасным сочетанием, особенно — в случае нагруженного и динамичного интерфейса, который не так уж и просто будет запилить в HTML5.

если прога в бекграунд уходит, винда ее снимает

Там есть возможноть выполнять задачи в бекграунде. Скайп, имейл клиент, калетндарь и т.п. так работают.

Вы написали очень скромно и не информативно, а нужно было так :
«Вы получаете новый геморрой и зп. Если не пугает поддержка старого, глючного Г0ВНА на давно не востребованном и почти дохлом WPF то в чём проблема ?»

Підписатись на коментарі