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

GetVolumeNameForVolume
QueryDosDevice

Также про вас:
stackoverflow.com/questions/26573933/hard-disk-vol...

1-й вариант: используйте Margin и Padding для достижения желаемого эффекта.
2-й вариант: используйте xml:space="preserve" в TextBlock-е, где нужно сохранить пробелы.

Делегаты - это реализация функтора на платформе .net. Функтор - это распространенная в современных языках базовая концепция, пришедшая из функционального программирования. Коротко её смысл в том, чтобы работать с функцией как со значением, наравне со значениями других, более привычных типов, вроде int или double. Т.е. функцию можно передавать в другие функции, возвращать из функций и так далее. В функциональных языках это обычное дело, однако и в императивных языках это даёт массу возможностей.

Количество применений делегатов в дотнете вообще и конкретно в C# огромно. Собственно, сам язык сегодня является частично функциональным из-за того, что широко используются делегаты и основанные на них возможности. Любая лямбда может быть скомпилирована в делегат. LINQ to Objects основаны на делегатах. События есть инкапсулированные делегаты. Любые callback-и в дотнете это делегаты. Список можно продолжать

Сравнивая C# с другими языками, делегаты часто называют "умными указателями на функции" в том смысле, что они похожи на указатели на функции в Си, но умеют еще и запоминать объект, для которого требуется вызвать метод, если метод нестатический. А вот в C++ есть прямой их аналог - это std::function.

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

'x' в previousExpression и 'x' в currentExpression считаются разными переменными. Необходимо явно указать, что одну из лямбд, например currentExpression, нужно вызывать с той же переменной, что и другую. Например, попробуйте так:

var result = Expression.OrElse(Expression.Invoke(currentExpression, previousExpression.Parameters[0]), previousExpression.Body);

И да, могли бы привести в порядок код, прежде чем вопрос задавать, минут 10 я только пытался понять что вы делаете. Вот как вы считаете, это строчка легко читается?

Expression<Func<int, bool>> filterFunctor, comparison = x=> x == corrections[1] || x == corrections[0];

Помимо того, что вы лямбду в скобки не берете, вы еще и две переменных в одном стейтменте объявляете.

GetBytes возвращает long, не знаю где вы нашли, что он возвращает массив байт:
https://msdn.microsoft.com/ru-ru/library/system.da...

Так что передача буфера третьим параметром более чем логична.

И оно кстати ругается: Cannot convert type long to byte[]

Да ладно вам?) А это не навело вас... на мысли относительно типа возвращаемого значения?) Вы сами придумали, что он возвращает массив байт?

тут еще как я понимаю размерность буфера предполагается указывать -- вопрос, а как узнать то сколько данных будет в самом блобе?

Ну вот если все таки пройдете в документацию, то ниже вы увидите следующее:

GetBytes возвращает количество доступных байтов в поле.Часто это значение равно точной длине поля.Однако возвращенное число может быть меньше фактической длины поля, если GetBytes уже использовался для получения байтов из поля.

При передаче буфера, значение которого равно null, метод GetBytes возвращает длину строки в байтах.

Поэтому, если вы не знаете длину буфера - вызовите метод с null для получения этой длины, создайте буфер и поместите туда значение вторым вызовом GetBytes.
В .net и C# нормальная документация, ее полезно читать.

Почему во всех примерах используются какие-то Streams?

Потому что BLOB они на то и BLOB, что Large Object. Блоб может быть килобайтовый, а может быть и гигабайтового размера. Гигабайт читать в массив целиком далеко не всегда целесообразно, как правило - вообще не целесообразно.

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

Александр Александров к сожалению, вынужден присоединиться к Сергей в том, что вы не знаете, что вам нужно от сервера.

Понимаете, все эти архитектурные паттерны - "бэкенды" в web-понимании, REST-ы - это все хорошо и удобно, но стандартные подходы web - это не всегда про игры и риалтайм-приложения.

Вы должны принять много различных решений, прежде чем браться что-то делать.

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

Многие крупные игровые проекты с большой долей логики на сервере используют свои протоколы обмена (как правило, бинарные) поверх обычного TCP-соединения. Многие применяют различные языки описания таких протоколов, чтобы было проще управлять разработкой, и вносить изменения в протокол (например, по таким описаниям можно автоматически генерировать часть серверного и клиентского кода). Например, Близзы, насколько мне известно, используют Protocol Buffers для Diablo 3.

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

возможность сохранить процесс прохождения игры

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