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

И да и нет. Тоже для обмена данными между приложениями, но не обязательно с использованием REST-архитектуры.

WCF он больше про классические веб-сервисы на базе XML и SOAP. Хоть в WCF и есть возможность создания HTTP REST сервисов, сложно сказать что WCF под них заточен.

В основном этот фреймворк ориентирован на разработку приложений на базе группы стандартов WS-*, например таких как WSDL, WS-Addressing и WS-Security. Это объёмные стандарты, написанные для обеспечения взаимодействия классических веб-сервисов (см. нулевой уровень, swamp of POX в Richardson Maturity Model ).

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

Классические веб-сервисы многими недолюбливались, в частности потому что:
а) REST-ом как правило и не пахнет, HTTP как правило использовался исключительно как транспорт для RPC: т.е. вместо GET/PUT/POST/DELETE/.. всегда вызывался POST с параметрами запроса в его теле. Цитата из ссылки:

These services have a single URI, and use a single HTTP method (typically POST). For example, most Web Services (WS-*)-based services use a single URI to identify an endpoint, and HTTP POST to transfer SOAP-based payloads, effectively ignoring the rest of the HTTP verbs.

б) стандарты группы WS-* очень сложные, все технологии на их основе просто не могут быть простыми (как и в частности WCF). Да, есть свои плюсы вроде "могу вызвать что угодно у кого угодно по какому хочешь протоколу", но не всегда такая гибкость была реально нужна.

Уже давно в многих новых системах наблюдается сдвиг к REST-архитектуре, как к более масштабируемой и простой для потребления клиентом, и, следовательно, протокол HTTP используется по прямому назначению, а не тупо как транспорт для сообщений. А там где REST неудобен/излишен и где RPC лучше походит, проще взять для этого более легковесный протокол или вообще поднять свой на базе какого-нибудь protobuf, как делают во многих игровых проектах.

Соотв-но WCF сегодня реже выбирают для разработки новых проектов, т.к. для него HTTP REST сервисы немного не "родные". Удобнее взять другие фреймворки вроде ASP.NET Core или Nancy.

Конечно у вас будет один и тот же массив, вы ведь его один раз создали снаружи цикла.

В C# массив - ссылочный тип. Это значит что ваша переменная anyArr хранит в качестве значения ссылку (!) на массив. Если вы скопируете значение переменной, что вы по сути делаете в строке arrList.Add(anyArr); вы скопируете эту самую ссылку на массив, но не сам массив (в результате ссылка на один и тот же массив будет помещена в список 6 раз).

Если хотите иметь 6 разных массивов - создавайте их в цикле, или копируйте исходный, смотря что вам нужно делать. В любом случае, вам нужно 6 разных объектов типа object[] .

Затем читайте про типы-значения и типы-ссылки в C#.

https://msdn.microsoft.com/en-us/library/system.io... - значение этого параметра нужно выставить в Read. Не стоит велосипеды городить, стоит изучить стандартную библиотеку.

Два примера решения одной задачи

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

Это настолько разные примеры, что даже непонятно, как вам эту разницу объяснить.

То, что вы просите, невозможно сделать по одной простой причине. Наследование в .NET бывает только "настоящее", т.е. когда устанавливается отношение is-a. Ваш MyTCPStream не может быть Stream-ом, если не реализует метод Read (Byte[], Int32, Int32). Спросите себя - что произойдёт, если я скастю объект MyTCPStream к Stream, и попытаюсь вызвать Read(Byte[]...)?

Вы конечно можете в теле метода бросить InvalidOperationException, но это однозначно признак неверно выбранной абстракции. Лично я не понимаю, зачем вам мог понадобиться TCPStream, из которого вы читаете не байты, а символы.

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

ODP.NET это надстройка над ADO.NET?

Ну у вас и каша в голове, неудивительно, что вы ничего не можете найти.

ADO.NET - это прежде всего набор интерфейсов, обеспечивающих написание кода, работающего с реляционными данными таким образом, что он минимально зависит (или не зависит вообще) от конкретной используемой СУБД. ADO.NET это далеко не первая попытка унифицировать интерфейс доступа к базам данных (хотя бы к реляционным), многие крупные вендоры это делали, тот же Борланд.

С момента появления дотнета как платформы ADO.NET был и остаётся основным способом доступа к реляционным БД из дотнет-приложений. В большинстве случаев нет причин НЕ пользоваться им. Стоит отметить, что хоть сейчас MS советует использовать ORM (с тех пор, как повзрослел Entity Framework) для доступа к данным, ADO.NET никуда не девался, т.к. все известные мне ORM-ми работают также через эти интерфейсы.

Провайдеров данных существует множество, и существование каждого из провайдеров определяется существованием конкретной СУБД. ODP.NET это не надстройка над ADO.NET, это реализация интерфейсов ADO.NET, способная взаимодействовать с Ораклом. Аналогичные провайдеры существуют и для других популярных СУБД, включая PostgreSQL, DB2, MySQL и даже SQLite. По сути доступность реляционной СУБД на дотнете определяется наличием работоспособного ADO.NET-провайдера.

Разумеется, конкретный провайдер может добавлять какой-то специфичный функционал, но при этом он должен реализовать все необходимые интерфейсы. Фишка ADO.NET в том, что реально написать такое приложение (разумеется, если пользоваться только стандартными SQL конструкциями), которое ВООБЩЕ не будет зависеть от конкретной СУБД вплоть до того, что нужного провайдера можно будет указывать в конфиг-файле.

Большинство интерфейсов и классов ADO.NET находятся в пространстве имён System.Data. Условно они делятся на собственно интерфейсы для доступа к БД (важнейшие из них: IDbConnection, IDbCommand, IDataReader) и классы-хелперы, в частности набор классов для организации простейшей in-memory базы данных внутри вашего приложения, которая будет служить кэшем для данных, взятых из основной БД (важнейшие классы: DataSet, DataTable).

Слышал что есть управляемые и неуправляемые провайдеры данных, в чем отличие?

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

Почитать об этом можно в любой нормальной книжке по дотнету. Если остались вопросы, пишите в комментарии.

- не надо ли переписать каждый UserControl в свой отдельный проект (.dll) и после этого тягать его в основное окно?

Проекты лучше делать по подсистемам или крупным компонентам в проекте, с учётом имеющихся зависимостей. Не видя вашей ситуации сложно посоветовать конкретное решение, но во всяком случае врядли каждый контрол стоит пихать в отдельный проект.

- что в общем можно прочитать про корректную архитектуру приложения (насколько я понял, вопрос именно по этой теме)?

Raffaele Garofalo, "Building Enterprise Applicatio...

- хотелось бы начать работать с версиями своего проекта. Visual Studio Team Services вроде как подходит, откуда начать изучение данного сервиса?

Лучше начните с Git. Можно конечно поработать и со Студийным контролем версий, но раз уж вы не работали еще вообще ни с чем, гит будет более универсальным скиллом ввиду его подавляющей популярности. И да, самое главное - вам не обязательно будет сразу пользоваться каким-то сервисом, проект можно версионировать и у себя на машине, и залить в VSTS при необходимости. Удивительно, как вы до сих пор не пользовались никакой VCS, видимо вы аккуратный и терпеливый человек)

Да, убедитесь что вы разобрались с MVVM. Может быть стоит подобрать фреймворк или самому собрать базовую библиотеку, если уже есть наработки.

NAudio (в нюгете).

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

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

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

C# это Java.
.NET это CLR и различные библиотеки (какие - зависит от формы поставки .NET, например .NET Framework, Silverlight или .NET Core).
CLR это JVM.
CIL это байткод Джавы.
ASP.NET MVC это Spring.
ASP.NET Web Forms это тоже веб-фреймворк, только с другой идеологией (более старый, чем MVC).

Что для чего нужно и что за умное словечко "платформа"?

Непонятен контекст.

GetVolumeNameForVolume
QueryDosDevice

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