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

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

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

Разумеется, два приведенных варианта не взаимоисключающие. Например, большинство пользователей (особенно внешних) могут работать через веб-сервис, которому выделен отдельный пользователь БД, а несколько человек из персонала, для большей гибкости работы с базой (администраторы, аналитики) могут иметь отдельных пользователей с более богатым набором прав.

С jsoncpp не работал, код написан по исходникам библиотеки:

for (const auto v : jsonObject["buffer"]["data"]) {
    const std::uint8_t b = static_cast<std::uint8_t>(v.asInt());
    // пишете b в файл
}

Что вы пытались сделать в приведенном коде, я так и не понял. Касательно записи в файл - история отдельная.

1. Многозадачность. Термин обычно не применяется к прикладному ПО, только к операционной системе, а точнее к ядрам ОС. Многозадачность - способость системного ПО распределять вычислительные ресурсы между несколькими параллельно (т.е. условно одновременно) запущенными вычислениями. Различают кооперативную и вытесняющую. Как правило, поддержка многозадачности сводится к тесной работе с железом и умению ядра сохранять состояние вычислительной системы (например, регистров процессора), и прозрачного переключения этого состояния для выполняющихся задач.

2. Многопоточность - вариант реализации вычислений, при котором для решения некоторой прикладной задачи запускаются и выполняются несколько независимых потоков вычислений, причём выполнение происходит одновременно или псевдоодновременно. В операционных системах, где термины "поток" и "процесс" различаются, под "потоком" понимают именно поток выполнения (ресурсами же владеет сущность, называемая "процессом"). Обычно применяется для распараллеливания вычислений на несколько вычислителей (процессоров и ядер процессора).

3. Многопроцессность - вариант реализации вычислений, когда для решения некоторой прикладной задачи запускается несколько независимых процессов. В системах, где под процессом понимается сущность, владеющая ресурсами (памятью, открытыми файлами, сетевыми подключениями), несколько процессов запускаются с целью повышения отказоустойчивости приложения а также с целью повышения безопасности. Т.к. ОС выполняет разделение памяти и прочих ресурсов именно между процессами (в то время как потоки работают в едином адресном пространстве), то а) внезапно упавший (читай - убитый ОС) процесс не уронит остальные; б) если в процессе начал выполняться чужеродный код (например, из-за RCE уязвимости), то он не получит доступ к содержимому памяти в других процессах. Многопроцессность сегодня можно увидеть в браузерах, когда отдельные вкладки выполняются в разных процессах, и упавшая вкладка (из-за js или из-за кривого плагина) тянет за собой не весь браузер, а только себя или еще пару вкладок.

При условии, что сама эта коллекция будет находится в экземпляре класса RemoteClientViewModel.

Не совсем понял, почему вы называете это "коллекцией", по логике я бы там ожидал увидеть просто несколько обычных свойств, выставленных для вьюхи. Чтобы сделать привязки к этим свойствам, просто задайте нужный ItemTemplate.

Кроме того, мне нужно чтобы при клике на элемент списка ListBox в ListView отображался соответствующий этому клиенту (т.е той ViewModel которая подключена к этому элементу) список файлов.

Всё очень просто - сделайте в MainViewModel свойство SelectedЧТОТО, в пару к вашей коллекции. Например, если коллекция это RemoteClients, то и свойство - SelectedRemoteClient. Забиндите SelectedItem ListBox-а к этому свойству. Разумеется, не забудьте его правильно реализовать, с NotifyPropertyChanged. Затем привяжите ItemsSource ListView-хи к SelectedRemoteClient.Files, где Files это коллекция с информацией о файлах. Если не будет работать, пишите, попробуем другой вариант.

Потому что ивент - это не то же самое, что делегат. Ивент ограничивает интефейс делегата только двумя операциями - добавить и удалить обработчик. Это делается для того, чтобы только изнутри объекта можно было сгенерировать событие. Иными словами, чтобы никто не мог, к примеру, "нажать" кнопку вместо самой кнопки (т.е. сгенерировать событие Clicked в обход внутренней логики класса "Кнопка"). В этом принципиальный смысл концепции событий.

Можно провести аналогию между полем/свойством и делегатом/событием. Как свойство - это в некоторых случаях "интерфейс" для поля, который позволяет контроллировать, как оно изменяется (при этом вы можете использовать генерируемое поле с помощью синтаксиса { get; set; }), так и событие это "интерфейс" для делегата - вы не можете напрямую изменять или вызывать делегат, вы делаете это с помощью события. Можете также почитать про синтаксис add/remove у событий - тогда аналогия со свойством будет еще понятнее.

Зачем делать InvokeEvent не совсем понятно, видимо это просто какой-то пример. В реальном коде класс MyClass должен сам решить, когда вызывать то или иное событие.

Ищите в C:\Users\имя_пользователя\AppData\Local

1. Нужно собрать релизную версию приложения. Не распротраняйте на другие компьютеры дебажные версии. Тогда "d" требовать не будет.
2. Т.к. приложение на C++, оно будет требовать рантайм. Этот рантайм можно как слинковать статически, так и оставить динамически загружаемым. Это настраивается в свойствах проекта. Если слинковать статически - то тогда dll не потребуется, но и обновить рантайм отдельно от приложения будет невозможно.
3. Если поставлять рантайм отдельно, как динамически загружаемый (т.е. чтобы была dll), то можно либо класть его рядом с exe, либо устанавливать redistributable версию райнтайма. Второе предпочительнее, т.к. тогда рантайм можно будет обновить с помощью системной обновлялки, если в нём будут найдены критичные проблемы.
4. Чтобы точно узнать, что требует EXE для своего запуска (не считая модулей, загружаемых с помощью LoadLibrary), воспользуйтесь Dependency Walker.

Более подробную информацию вы сможете получить на MSDN в разделе деплоя C++ приложений.

1. Делаете хороший README, разумеется на английском, где указываете, как ей пользоваться, и что ей требуется.
2. Делаете несколько примеров (именно рабочий код в подпапке examples) для основных кейсов применения библиотеки.
3. Льете на опенсурсный хостинг, если еще не сделали.
4. Настраиваете CI (например на AppVeyour), это не обязательно, но желательно.
5. Заливаете готовые пакеты на NuGet. Разумеется, вы должны научиться упаковывать свою библиотеку в нормальный пакет. В nuspec ставите годные правильные теги.
6. Покрываете тестами, хотя бы частично.

После этого к вашей библиотеке начнут относиться более-менее серьезно.

7. Можете попробовать на CodeProject рассказать, там часто рассказывают именно про библиотеки.

Удалите папку .vs рядом с солюшеном и user-файл рядом с проектом, если такой есть.

То, что вы сейчас делаете - это EAV (Entity–attribute–value), можете гуглить по этому термину. А вообще советую переместить параметры товаров в документную базу (ибо EAV это костыль).