Станислав Макаров

А у MVVM нет общих правил, каждый реализовывает его по-разному.

Ну я б не говорил, что их прям нет. Есть привязки, есть INotifyPropertyChanged, есть рекомендации от MS. Да, вы правы в том смысле, что WPF это библиотека, но НЕ фреймворк для разработки, т.е. она не регламентирует структуру приложения.

И у меня диссонанс — что сначала изучать, куда копать, что вообще делать, что стоит изучать, а что нет.

Вот пару дней назад советовал книгу: Raffaele Garofalo, "Building Enterprise Applicatio... - если ничего не читали еще, начните с неё.

И действительно хороших, многофункциональных и понятных проектов на WPF + MVVM я не видел.

Неудивительно: WPF-приложения это обычно line-of-business, а это не open-source по определению.

С чего начать изучение WPF?

Убедитесь, что более-менее понимаете платформу .NET и ООП в ней, иначе будет тяжело.
Вам надо будет разобраться:
а) с системой зависимых свойств (dependency property);
б) c MVVM и INotifyPropertyChanged;
в) само собой с XAML и контролами, принципами написания своих контролов;
г) со стилями и стилизацией;
д) с системой команд (ICommand) и прочим.

Нужны ли MVVM-фреймворки? Почему столько дискуссии возникает. Одни говорят да, другие — нет.

Дискуссии возникают потому что а) некоторые вещи можно сделать разными способами; б) разработчики имеют дело с приложениями разного размера и сложности, но редко об этом задумываются в спорах; в) опытные разработчики нередко сами себя уже обеспечили нужным "библиотечным" пока разрабатывали приложения (ViewModelBase, хах :) ). Лучше пока разберитесь сами как что работает, потом поймете, какой фреймворк вам пригодится.

Впоследствии еще советую познакомиться с IoC-контейнерами, если еще не пользовались. Это общий совет для крупных приложений, не только для WPF. Некоторые имеют спецальные интеграционные библиотеки для работы на пару с фреймворками, например Autofac: Prism.Autofac.

Сначала изучите C# и .net fw откуда угодно (1000 и 1 ответ на Тостере уже есть), чтобы не задавать такие вопросы.
Очевидно же, что язык и даже платформа не имеет отношения к кокнретным интерфейсам. Тем более UI-подсистема.

Вы как планируете управлять ими, через COM-порт?

Добавлять созданием объекта чарта. Привязывать, например, биндингами, как в примере.

Вы C# и WPF впервые видите?

на изменение выделенного элемента

Ежели так, то вам нужен TreeView и OnSelectedItemChanged.

Raffaele Garofalo, "Building Enterprise Applications with Windows Presentation Foundation and the Model View ViewModel Pattern"

www.oreilly.com/pub/pr/2761

<TreeView ItemsSource="{Binding СвойствоОбщейВьюМоделиСодержащееКоллекциюЗаписей}">
    <TreeView.ItemTemplate>
        <HierarchicalDataTemplate ItemsSource="{Binding СвойствоОбъектаСсылающеесяНаОбъектРодитель}" DataType="{x:Type local:КлассОбъекта}">
            <TreeViewItem Header="{Binding СвойствоВОбъектеСТекстомДляОтображенияВУзле}"/>
        </HierarchicalDataTemplate>
    </TreeView.ItemTemplate>
</TreeView>

Не забудьте добавить описание неймспейса local.

Правильно ли я сделал, что определение класса самого объекта из списка расположил в проекте wcf-сервиса? Класс списка со всеми операциями я расположил там же.

Зависит от вашего задания. В принципе для такого тестового не вижу смысла заморачиваться разбиением на проекты.

сейчас я скопировал адрес из wcf-test-client и вставил как service reference в wpf

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

А в чем проблема-то? Если прога не работает - считать, что юзера нет за компом. Ну как трекер для того же Upwork-а работает.
Это если цель - заставить юзера быть заинтересованным в генерации активности на компе. Если цель другая - см. ответ АртемЪ - он подходит, если вы администрируете машины пользователей. Если машины админятся самими юзерами (т.е. у вас не исключительных прав на них) - то тогда, имхо, и надежного метода нет по определению. Безопасная загрузка, загрузка с другого носителя, и т.д.

Все предельно просто - dependency properties это попытка получить реактивное программирование конкретно в рамках WPF и с минимальными затратами (без модификаций на уровне языков/платформы .net).

Вы формулами в Экселе когда-нибудь пользовались? Вида =A1+A2+A3? Когда обновляешь ячейку A1 и автоматически обновляются все значения, вычисляемые по формулам, в которых встречается A1. Вот это примерно то же самое. Почему это так важно в WPF? Потому что а) это естественный способ связи свойств визуальных компонент друг с другом и с ViewModel-ью - без свойств зависимостей обновление зависимых значений превращается в адские цепочки Refresh-ей, Recalc-ов и прочего, и дай бог не забыть вызвать все нужные пересчеты. б) это дает механизм абстрагированной обработки и изменения свойств объектов (как правило - контролов), более производительный и узкоспециализированный по сравнению со стандартной рефлексией. Это, в свою очередь, обеспечивает возможность без лишних заморочек написать классы вроде DoubleAnimation, с помощью которого можно анимировать ЛЮБОЕ (!) свойство типа double у любого объекта, лишь бы оно было dependency property.

MSI-пакеты тоже вариант, если проект большой и нужны широкие возможности.

разработка остановилась 5 лет назад и тому подобное

Да, есть некоторый застой, основные силы переброшены на .net core и asp.net

Правда ли, что WPF ждет судьба WinForms?

Что конкретно вы имеете в виду под "судьбой WinForms"?

Есть ли альтернатива WPF?

Под .Net нету, под WinRT есть аналогичная подсистема, во многом скопированная с WPF, вообще под десктоп есть еще Qt, но это C++ (если не считать биндингов на другие языки)

Что сейчас Microsoft предлагает для разработки GUI?

Universal Windows Platform для Windows 10 - их основное направление, для классического десктопа - ничего нового.

что WPF уходит в прошлое

Альтернативы под .net нету, никуда он уходить не может (не все пока хотят связываться с Metro и UWP приложениями).

1) определитесь, что у вас будет базовым документом. Т.е., чего у вас будет много. Сейчас, я так понимаю, это заказ. Итак, это документ и он будет множиться. Советую его сделать табами.
2) информационная панель и список пользователей вполне могут быть сделаны док-панелями справа и слева. Причина проста - на них придется часто смотреть, следить за ними. Постоянно переключаться не вариант. Правда, тогда они должны быть не так обильно наполнены элементами, как панель заказа, но мне кажется у вас как раз так и будет. Если у вас на инф. панели в основном сообщения, а на вкладке "список пользователей" - только этот список, ты выделять под такое весь экран нет смысла.

Итого: слева инф. панель (15-20%), справа список пользователей (15%), оставшееся по центру - таб-контрол для заказов, по принципу табов в браузере (можно даже плюсик сделать для создания нового заказа). Альтернативный варинт - инф. панель снизу, под таб-контролом для заказов

Есть еще либа на свете - NAudio. Можно ей попробовать. Возможно, она сама не умеет качать по урлу, тогда скачайте сами WebClient-ом и отдайте либе.

> При этом реализовать это без использования INotifyPropertyChanged.
Вы хотя бы коротко причину указали, почему так нельзя делать. Почему меня интересует причина? Потому что если вы скажете "я не хочу забивать чистенькие модельные классы, которые используются в нескольких проектах всякими непонятными INotifyPropertyChanged" я вам отвечу "а и не нужно их трогать, для реализации INotifyPropertyChanged создаются ViewModel-объекты, которые и привязываются к контролам вместо модельных. Они и реализуют INPC, кроме того могут выставлять во вьюху некоторые свойства, которых нет в модельных объектах".
А если вы скажете "я тут экспериментирую", то тогда можете запилить DependencyProperty у себя в привязываемом объекте, хотя это довольно странно. Но работать должно.