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

Начните с https://msdn.microsoft.com/en-us/magazine/dd419663.aspx .

После прочтения статьи должны придти к выводу, что главное а) построить правильную ViewModel; б) записать правильные привязки. Не факт, что получится обойтись без генерации контролов из кода. Но даже в этом случае содержимое статьи должно быть применимо.

Вот мой джентельменский набор на Винды:

• .net fw последний, чтоб все работало
  
• 7-zip
  
• SumatraPDF/Adobe Reader
  
• Far Manager (да, люблю, такой вот извращенец)
  
• foobar2000
  
• VLC
  
• OpenVPN
  
• TeamViewer
  
• PuTTY
  
• Deluge
  
• Skype, опционально Telegram
  
• DAEMON Tools Lite
  
• Steam, GOG Galaxy
  
• Beyond Compare
  
• WinDjView, опционально Ghostscript+gsview
  
• Sandboxie по первой необходимости
  

Все прочие Фотошопы, AE-шки, Гиты, WebStorm-ы и Студии понятное дело зависят от вашего рода деятельности.
Антивирус не держу (он нужен только когда ты недавно за компом и еще не можешь сам набрать foobar2000.org, чтобы скачать нужный тебе софт), файрволла на виндовой машине нет.

99%, что удаленная функция - это конструктор копирования.
По смыслу объекта сокета можно догадаться, что копировать его не стоит (т.к. так или иначе он представляет собой обертку над системным ресурсом). Раз его копировать не стоит, используйте указатель на сокет вместо самого сокета. Например, shared_ptr, вот как тут советуют: stackoverflow.com/questions/5425666/passing-around... .

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

1) олдскульные (SOAP/XML) веб-сервисы называли так, потому что есть группа стандартов от W3С, и там используется именно понятие "web service" (https://www.w3.org/TR/ws-arch/#id2260892);
2) поэтому REST API называются так, чтобы побольше отличаться от веб-сервисов, и заодно подчеркнуть, что в таком взаимодействии единственный стандарт "для всех" - это HTTP. Все остальное - форматы запросов/ответов, степень соответствия архитектуре REST - определяется конкретным сервисом, и поэтому хотелось некий "легковесный" термин, который бы говорил о таких контрактах взаимодействия, которые работают поверх HTTP и соответствуют архитектуре REST. Поэтому и REST API/Web API , что переводится как "контракт, работающий поверх HTTP в соответствии с архитектурой Web".

А вам надо по-другому? У вас есть залогиненый юзер, вы где-то держите его id. Теперь, когда залогиненный юзер оформляет заказ, вы добавляете новый заказ этому юзеру, указывая конкретный user_id при insert-е записи в таблицу заказов.
Смысл внешнего ключа в том, что СУБД не позволит вам добавить заказ на несуществующего юзера. Т.е. при insert-е автоматически произойдет проверка, что в родительской таблице юзеров есть запись с таким id, который вы указали в добавляемом заказе.
Вы можете делать такой insert и без внешнего ключа, вам вообще не обязательно пользоваться внешними ключами - все равно все нужные выборки вы будете делать сами. Внешние ключи это лишь один из видов ограничений целостности, грубо говоря доп. проверка со стороны СУБД, чтобы вы могли чувствовать себя спокойнее за согласованность базы (вам же не очень хочется, чтобы в случае какой-либо досадной ошибки в приложении у вас добавился "висячий" заказ вообще непонятно на кого). Ну и еще они позволяет выполнять некоторые каскадные операции, например удалить все заказы при удалении юзера - если конечно вы так позволите делать.

Совершенно верно Петр говорит, this в мешке не утаишь).

Кроме того, если либа грузится через LoadLibrary, т.е. связывания на этапе компиляции нет, то и вызывать ее надо через указатель, а тогда без обертки соответствие между какой-либо функцией, объявленной в классе (пусть даже это будет статическая функция) и этим указателем не проставить в принципе, т.к. где-то должна произойти косвенная адресация и передача управления в DLL.

1) проверьте, выполняется ли nuget restore. Вот прям сами откройте packages, зайдите в папки конкретных пакетов и проверьте что там лежат скачанные сборки
2) к сожалению в классических проектах на C# (не DNX) взаимодействие с NuGet довольно посредственное. В том смысле, что содержимое проекта и packages.config может рассинхронизироваться (ввиду отстутсвия единого списка пакетов/сборок, как это сделали в project.json). Т.е. в packages.config все будет, но в csproj эти ссылки не будут прописаны.
Выход из ситуации - открыть ручками csproj и поставить нужные Reference, прописав относительные пути на сборки в packages, вроде таких:

<Reference Include="NetTopologySuite.IO.ShapeFile">
      <HintPath>..\..\packages\NetTopologySuite.IO.1.13.3.2\lib\net40-client\NetTopologySuite.IO.ShapeFile.dll</HintPath>
    </Reference>

Конкретный путь надо смотреть вам (на сколько уровней "выйти" и в какие папки "зайти"). Сначала нужно, конечно, проверить, нет ли уже этих ссылок - возможно просто папка packages почему-то уехала на новое место, и пути просто испортились.