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

1) убедиться, что все зависимости имеют версии для .net 4.0 или ниже
2) переделать те места в коде, которые используют фичи C# > 4.0
3) сменить версию целевого .net framework на 4.0 в свойствах проекта

Как добавить товар в корзину?

- EAV (ссылку дал @muhammad_97);
- JSON/XML в реляционной базе;
- JSON в документной базе (CouchDB/MongoDB) (предпочтительный вариант);

Делегаты - это форма существования функтора на платформе .NET. Почитайте про функтор, и поймете (наверное), зачем нужен делегат.

Если коротко и грубо - вызвать напрямую можно всегда только конкретный метод, который будет четко известен еще на стадии компиляции. Если же вы пишете некий обобщенный алгоритм и заранее не знаете, какие КОНКРЕТНО методы у каких КОНКРЕТНО объектов будете вызывать - вам необходимо будет воспользоваться делегатом.
Простейший пример - LINQ-методы. Метод фильтрации Where получает своим параметром функтор, который возвращает true или false, что значит - оставить элемент в коллекции или выкинуть его. В этом методе в цикле foreach вызывается переданный делегат для каждого элемента. Where понятия не имеет, какой конкретно метод (или лямбда-выражение) вы захотите подставить в качестве фильтрующего предиката.

Другой пример - события. События в дотнете - это делегаты с урезанным публичным интерфейсом. Так как, к примеру, кнопка не знает о том, кто захочет подписаться на событие ее нажатия, она никак не может вызвать конкретные методы у конкретных объектов. Чтобы иметь возможность сообщать о своем нажатии, кнопка выставляет событие Click наружу, давая возможность записать туда конкретные методы для вызова.

Кстати, делегат выполняет еще и функцию связывания: для нестатических методов делегат хранит еще и объект, для которого будет вызван instance-метод (т.е. связывает пару объект-метод).

Таким образом,
> Почему методы нельзя передавать в функции без делегатов?
Делегаты - это и есть передача методов в функции.

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

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

Классы, как и процедуры/функции - это простейшие кирпичи для построения дома. Библиотеки - это когда вам подгоняют готовую кухню/ванную или водопровод, который вы встраиваете в ваш дом.

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

В целом я понял вопрос как "зачем нужны гайки и болтики, если я могу сделать мотор или купить его у мотозавода?". А вы/мотозавод, собственно, из чего будете мотор собирать?

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

Главная фишка ссылки в том, что это абстрактное l-value, т.е. сущность, в которую можно что-то присвоить (если базовый тип - не константный). То есть ссылка всегда оборачивает какой-либо адрес в памяти, причем на время жизни ссылки этот адрес постоянен (ссылку нельзя "переставить" на другую область памяти). Именно поэтому ссылки всегда нужно инициализировать.
ЧЕМ инициализировать - другое дело. Можно переменной, а можно - разыменованным указателем.

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

Теперь попробуем сранить ссылку и другие сущности в языке.
Определение ссылки vs определение обычной переменной:
определение обычной переменной это всегда выделение памяти и добавление нового имени в таблицу компилятора для этой области памяти. Определение ссылки - это прежде всего ОПРЕДЕЛЕНИЕ ИМЕНИ, а уже в тех случаях, когда привязку этого ИМЕНИ к АДРЕСУ невозможно осуществить во время компиляции (т.е. например в случае передачи ссылки как параметра функции), то для реализации ссылки применятся указатель. Важно, что компилятор сам выбирает способ реализации поведения ссылки. В любом случае, назначение ссылки - обернуть в l-value уже ВЫДЕЛЕННУЮ память (совершенно не важно, на стеке, куче или где-то еще). Новой памяти для хранения значения целевого типа НЕ выделяется. Если у вас есть переменная и ссылка/несколько ссылок на нее, то при присвоении значения через любую из сущностей вы будете менять одну и ту же область памяти.

Ссылка vs указатель:
- самое важное отличие - указатель САМ ПО СЕБЕ является переменной. Под указатель int* компилятор выделит память также, как и под int. Указатель существует сам по себе, ему (если он не const) можно присваивать новые значение, можно присвоить nullptr. Можно даже хранить в нем совершенно некорректный адрес и все будет ок до тех пор, пока вы не разыменуете его. Только когда вы разыменовываете указатель, вы превращаете его в l-value, и с этого момента между ним и ссылкой разницы нет.
- второе отличие - собственно необходимость разыменования. Т.к. указатель - самостоятельная переменная, для обращения по адресу, на который указатель смотрит, нужно сделать ему *p. Именно в этот момент компилятор начинает рассматривать значение указателя как адрес в памяти, с которым вы собираетесь что-то сделать (если быть совсем точным, но не в момент разыменования, а при попытке чтения/записи. В принципе вы можете даже инициализировать ссылку некорректным указателем, и программа не упадет, пока вы не попытаетесь читать/присваивать по этой ссылке).
- с учетом сказанного, ссылку можно грубо считать "константым указателем с автоматическим разыменованием". Грубо, т.к. согласно стандарту есть нюансы, такие как вышеупомянутое продлевание жизни временным объектам.

Чет так и не понял в чем проблема.. Если папка скрытая - то включи отображение скрытых папок, если к папке нет доступа, то открой командную строку в этой папке, и
cacls *.* /T /G ALL:F

Можно, либо получаете доступ к инфраструктуре сервиса и ковыряете трафик еще до отправки клиенту, либо ставите на клиента поддельный корневой сертификат, и можете пускать трафик через себя. Посмотрите как делает Fiddler на локальной машине, чтобы перехватывать HTTPS трафик. Если вы сможете установить липовый сертификат, то сможете и перешифровывать на middle-стороне трафик, создавая иллюзию нормального HTTPS соединения.

Зависит от того, какую ответственность вы "отдаете" в класс. Если это так называемый "value object", т.е. некий неизменяемый композит, то лучше ему в конструктор передать сразу готовые значения. Если же это самостоятельный объект с внятным жизненным циклом и определенной ответственностью - тогда конечно логично чтобы он сам брал данные из репозитория.
Вам нужно почитать про Dependency Injection - это как раз та "середина" между двумя альтернативами, что вы предложили в виде фрагментов кода. Обращаться к глобальном объекту репозитория - это также антипаттерн. Гораздо лучший вариант - это когда объекту при создании передается (!) репозиторий в конструкторе, а объект уже САМ делает выборки необходимых данных. Это как раз и есть удачный вариант спуска от общего к частному. Плюс, вся логика сосредоточена в классе - я всегда могу добавить новую Модель (если следовать вашим примерам), которая также берет репозиторий, но вытаскивает из него уже ДРУГИЕ сведения.
Вот стандартный туториал, в котором роль вашего "класса" выполняет ASP.NET-контроллер, и он получает репозиторий в конструкторе: www.asp.net/web-api/overview/advanced/dependency-i...

Вообще принцип всегда такой - если есть некоторая переменная или значение, то есть N точек, из которых можно получить к ней доступ. Чем меньше этих точек - и при этом вы можете без извращений реализовать нужную вам бизнес-логику - тем лучше. И чем ближе в коде эти точки расположены друг к другу - тем лучше. Всегда удобнее работать с кодом, когда данные конкретной сущности и логика их обработки умещаются хотя бы в одном файле.