Дотнет из коробки, прямо вот сразу готовый к использованию, появился ЕМНИП только в Win8. И это всегда была проблема дотнета, отсутствие его рантайма у большинства юзеров. Винда, а именно WinXP, если правильно сконфигурирована, вполне надежная и предсказуемая система (в частности, если отключено все лишнее и не абсолютно необходимое, в т.ч. сеть, звук, проводник и т.д.). Простые вещи на ней можно делать (напимер дозатор песка или цемента). Тот кейс, что вы приводите, требует многоуровневой распределенной системы управления, и на каждом уровне будут свои решения (начиная с датчиков и автоматики на уровне железа, до контроллеров сбора данных и операторских пультов, заканчивая SCADA системой которая все это объединяет). Понятно что одним компом с виндой и поделкой на шарпе тут не обойтись.
Майкрософт и так ни за что не несет ответственности, так что их предупреждения до одного места. А насчет взорвется или задавит, это ваши собственные фантазии. Требования определяют инструмент, и с этим никто не спорит. Требования просто разные бывают, как и сумма, которую за это готовы заплатить.
Да знаю я, с чем оно связано. Хорошо настроенная WinXP без всяких излишеств, не предподносит никаких сюрпризов по времени реакции. Там где тех.процесс допускает задержки до десятков мс, нет никаких причин не применять десктопные решения вроде Windows и C#, для создания встраиваемого ПО. Вас кстати не смущает, что MS выпускала и до сих пор выпускает специальные редакции Windows, называемые Embedded? Все отличие которых от десктопных, составляет 15 лет гарантированной поддержки и чуть ли не пофайловая конфигурация образа. И Embedded на самом деле, это не про размер, а про назначение, ПО и системы.
Реальное время, скажем так, может иметь разную степень «реальности». А процессы, которыми управляет ПО на C#, могут иметь определенную цикличность. Тогда в удобные моменты, достаточно просто вручную запускать сборку мусора, что с достаточно высокой надежностью гарантирует от возникновения проблем на критичных участках. Плюс, дополнительно можно отслеживать метрики по управляемым ресурсам (например памяти) и заранее принимать меры при достижении опасных уровней. Но обычно, на C# пишут то, что такого контроля не требует, а (теоритически возможные) задержки в 10-20 мс на процесс особо не повлияют. По шине RS-485 скажем, интервал опроса обычно десятки миллисекунд, за это время GC успеет 100 раз отработать.
Ну так о чем мы спорим тогда. Если добавляются требования Мак, Линукс, установка на пользовательские компы, то это уже не embedded тогда, и выбор инструмента должен учитывать эти требования. И в таком случае, очевидный (для меня) выбор инструмента — Qt. Я даже больше скажу — если бы Qt в том виде как он есть сейчас, появился на 15 лет раньше, то и C# мог бы умереть, не родившись.
Да нормально C# подходит. Железо готовое — модули от ICP-DAS, управляются командами по RS-485. На C# пишется логика всего процесса. И т.к. это специальное ПО под специальный комп, на котором больше не будет (не должно) ничего работать, то вполне можно поставить туда любую винду и наваять хоть на C# 2.0 нормальное приложение, которое легко дебажить и поддерживать. И которое будет работать годами (при соответствующей настройке винды). Я этим как бы занимался, несколько лет.
Ну так и автоматизация через UART, тоже вполне себе происходит в реальном времени. Например дозатор чего-нибудь — получаем параметр, смотрим уже хватит или еще подождать, когда хватит посылаем команду железу что-то выполнить. При этом можно отправлять данные куда-то на сервер, и показывать красиво в UI. И такое ПО, по определению, тоже будет являться встраиваемым. Требования к нему просто, менее жесткие. Особенно если железо — штучный товар. Я уже молчу про софт для банкоматов и кассовых терминалов — там C# аж бегом можно применять.
На C# вполне можно пилить автоматизацию под железо, особенно если это железо подключено через последовательный порт :) И это будет вполне себе embedded, по определению. Четырех-ядерного Intel Core на это вполне хватает)
Неохота разбирать все по каждой фразе, но вобщем — дискуссия несостоятельна. В том смысле, что у каждого инструмента есть своя ниша, и есть своя устоявшаяся практика. Аргументы насчет быстрого развития C# и медленного C++, это как раз больше аргументы в пользу C++, т.к. быстрое развитие обесценивает знания и опыт, и инструменты постоянно находятся в лучшем случае в руках «экспериментаторов». Т.е. мало кто знает, как лучше, и как надо — а делают так, абы работало. На выработку правильных подходов уходят годы, и когда инструменты меняются, это все идет коту под хвост. Кому нужно такое развитие, если от этого страдает качество?
Ну и пара слов насчет UI — прекрасно он делается и на C++, спасибо Qt. Тем кто скажет, что Qml это не плюсы, я отвечу, что и XAML как бы не C#. И даже UI на основе QWidgets гораздо ближе к XAML, чем WinForms.
А самый фундаментальный недостаток C# — это то, что им по прежнему рулит Microsoft, что бы там ни говорили про .NET Foundation и прочие игры в open source. А Microsoft давно потеряла доверие, вспомним что было с Windows Phone, с Silverlight, с .NET Compact / Micro Framework — где это все? Это корпорация, где шла война кланов, и где победил Azure. Вот и все, что нужно знать про эту (гнилую) контору.
С qmake есть проблема, что всякие нетривиальные штуки в нем плохо документированы. Например глобальный кэш переменных, или те же пользовательские цели для make. И еще сам QtCreator не очень хорошо парсит включаемые проекты (*.pri), особенно если там есть части, зависящие от токенов в CONFIG. Также если есть платформо-зависимые части, то QtCreator показывает их все в дереве проекта, независимо от текущей платформы. Ну это больше проблемы QtCreator, собирается оно нормально. Могли бы лучше интегрировать конечно.
Чего-то никто не вспомнил о системе сборки Chromium (gn+ninja), хотя она тоже кросс-платформенная и очень эффективная. Может генерить проекты для MSVC и XCode, а также списки файлов + DEFINES для QtCreator. Основной язык Python, это одновременно и плюс и минус (минус потому что только Python, обычную команду из системы напрямую вызвать нельзя).
Насчет среды, пока ничего удобнее QtCreator для себя лично не нашел. К сожалению под Windows все портит отладчик, глючный и неудобный (cdb). Но под Mac все супер. Также и система сборки qmake — с одной стороны, дает достаточную гибкость и расширяемость (можно создавать свои цели для make), с другой — легкость сопровождения и поддержки. Ну и встроенная документация в QtCreator тоже не последнее дело. Вместо nmake под Windows используется собственная тулза jom.exe (многопоточный make). Под Mac можно добавить ключик -j для стандартного make, с тем же эффектом. Также можно определять произвольные компиляторы/трансляторы для любых исходников (например protobuf), и компилировать все за один проход.
Также у Qt заявлено в планах расширять поддержку CMake для QtCreator, к сожалению эта уродливая дрянь побеждает всех (они даже отказались от собственного qbs, увы).
Такие вещи, как ReportViewer, нужно ставить через Bootstrapper (MS ClickOnce bootstrapper или новый Wix Burn). Они позволяют отслеживать зависимости и устанавливать все по очереди, например сначала .NET, потом SqlServerClrTypes, потом ReportViewer. Каждая MSI продукта должна устанавливать только этот продукт и ничего больше. Как вариант, иногда можно использовать Merge модули, если они есть готовые (как например VC Runtime).
Что касается установки Postgres-a, то у вас тут все очень упрощено. Как вы обрабатываете Rollback установки? А если это не установка, а обновление или удаление, и пользователь нажал Cancel? А при удалении, Postgres тоже удалится? А база? На все эти случаи в Wix есть CustomActions, которые должны срабатывать по условию. Правильно определить условия — задача нетривиальная, т.к. кроме разных сценариев установки (Install/Remove/Modify/Repair), есть еще подвиды commit и rollback на каждый CustomAction, выполняемый во время InstallExecute последовательности. Короче, что я хочу сказать — Wix# создает обманчивое впечатление, что создать установщик это просто. На самом деле, если хочется простоты, нужно использовать продукты с ограниченным функционалом, типа NSIS, а если простоты мало, тогда инвестировать время в изучение Wix/MSI. Остальные варианты не способны дать качественный результат.
GPS понятно, а зачем походникам телефон? Разве не лучше брать радиостанцию ватт на 5, которая работает в любых условиях? Правда она конечно тяжелее телефона.
О зип-бомбах в фидошные времена слышали? Были такие специально подготовленные архивы, которые при распаковке создавали файл размером, несоизмеримо большим чем размер самого архива (скажем с коэффициентом расширения 100000%). В итоге получив несколько таких файлов под видом эхо-почты, узел переставал работать, т.к. у него заканчивалось место на диске. Шутника конечно было легко вычислить, но способ был известен.
Если присвоение было законно, то за что сажать? И потом, напомните мне кого еще посадили после Ходорковского с Лебедевым, а то такое чувство, последние воры на Руси.
Ну и что? Вот не верю, что все такие честные и порядочные, не воруют из бюджета и налоги платят, а Ходорковский негодяй и потому сидит. Смешно же, да? Особенно учитывая его полиитические успехи как раз до ареста.
Оборжаться просто))) Интересно, за что же его все любят? И где были бы плюсы сейчас, если бы не Qt?
Ну и пара слов насчет UI — прекрасно он делается и на C++, спасибо Qt. Тем кто скажет, что Qml это не плюсы, я отвечу, что и XAML как бы не C#. И даже UI на основе QWidgets гораздо ближе к XAML, чем WinForms.
А самый фундаментальный недостаток C# — это то, что им по прежнему рулит Microsoft, что бы там ни говорили про .NET Foundation и прочие игры в open source. А Microsoft давно потеряла доверие, вспомним что было с Windows Phone, с Silverlight, с .NET Compact / Micro Framework — где это все? Это корпорация, где шла война кланов, и где победил Azure. Вот и все, что нужно знать про эту (гнилую) контору.
Насчет среды, пока ничего удобнее QtCreator для себя лично не нашел. К сожалению под Windows все портит отладчик, глючный и неудобный (cdb). Но под Mac все супер. Также и система сборки qmake — с одной стороны, дает достаточную гибкость и расширяемость (можно создавать свои цели для make), с другой — легкость сопровождения и поддержки. Ну и встроенная документация в QtCreator тоже не последнее дело. Вместо nmake под Windows используется собственная тулза jom.exe (многопоточный make). Под Mac можно добавить ключик -j для стандартного make, с тем же эффектом. Также можно определять произвольные компиляторы/трансляторы для любых исходников (например protobuf), и компилировать все за один проход.
Также у Qt заявлено в планах расширять поддержку CMake для QtCreator, к сожалению эта уродливая дрянь побеждает всех (они даже отказались от собственного qbs, увы).
Что касается установки Postgres-a, то у вас тут все очень упрощено. Как вы обрабатываете Rollback установки? А если это не установка, а обновление или удаление, и пользователь нажал Cancel? А при удалении, Postgres тоже удалится? А база? На все эти случаи в Wix есть CustomActions, которые должны срабатывать по условию. Правильно определить условия — задача нетривиальная, т.к. кроме разных сценариев установки (Install/Remove/Modify/Repair), есть еще подвиды commit и rollback на каждый CustomAction, выполняемый во время InstallExecute последовательности. Короче, что я хочу сказать — Wix# создает обманчивое впечатление, что создать установщик это просто. На самом деле, если хочется простоты, нужно использовать продукты с ограниченным функционалом, типа NSIS, а если простоты мало, тогда инвестировать время в изучение Wix/MSI. Остальные варианты не способны дать качественный результат.