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

Пробовали в диалоге "Свойства системы" на вкладке "Удаленный доступ" снимать галку "Разрешить подключения ... с проверкой подлинности на уровне сети"? Если подключаетесь клиентом с более новой версией, все должно работать..

точку с запятой после class BaseModel { .. } не забыли поставить?

Совет по общей структуре: в классе формы многовато данных. Понятно что с нее вы начинали все писать и из нее все вызывается, но время от времени нужно выделять группы данных/методов и выносить в отдельные классы или модули (в случае шарпа - это т.н. "статические" классы). Я по вашему коду разбил бы примерно так:
- хелперы для загрузки данных через прокси (и их автоматического переключения в случае ошибки - я правильно понял?): можно вынести в отдельный УмныйЗагрузчик, который заберет в себя всю логику пробивания к данным - перебор юзер-агентов, сбор статистики и т.д. Из этого умного загрузчика должны торчать: простой метод для загрузки нужного урла, простой метод для получения статистики, пусть даже текстом. На форме останется лишь присовение этой статистики textBox.Text;
- парсер html-контента. Всю логику поиска данных на странице убрать в него.
- общий координатор работ - можно слить с предыдущим пунктом, можно выделить отдельно. Я бы убрал в него бэкграунд-воркеров, например, не обязательно им на форме торчать.
- код записи данных в базу тоже стоит вынести. Сделайте простейшие POCO-классы для данных, которые извлекаете из html, возращайте объекты из парсера и передавайте в сохранялку.
- ну и конечно сохранение настроек - это прекрасно отделится от всего остального также в отдельный класс.
Разумеется нужно разбивать не только код, но и данные вместе с ним - вы сами увидите, как все станет проще и читабельнее, когда public static int CounterProxy = 0; будет в одном файле, а const string strWinState = "WindowState"; - в другом.

Ну а теперь по мелочам:
- не злоупотребляйте static-ами: статических данных в программе обычно немного, и это как правило объекты, с которых приложение начинает "жить" - и то лучше взять IoC-контейнер для этих целей. В вашем случае, когда вы разобьете код на классы, сами поймете что статики в таком количестве вам не нужны.
- ArrayList я уже давно не видел в коде, не знаю в каком учебнике вы его нашли. В вашем случае он тем более ни к чему. Используйте List<T> и не извращайтесь вот так: Agent[CounterUserAgent].ToString();
- сразу давайте всему внятные имена, в т.ч. контролам. Это сейчас у вас button1 и button2, а завтра будет button42.
- используйте xml-документацию, раз уж делаете комментарии к методам
- по возможности привыкайте пользоваться английским - довольно мало команд разработчиков могут себе позволить использование родного языка в коде.
Для начала достаточно. Прежде чем заморачиваться паттернами, ощутите на нескольких примерах как вообще пользоваться ОО-языком, что он вам дает и что требует от вас.

Алгоритм получения ответа на ваш вопрос, которым я воспользовался и также советую вам:
1. Идем смотрим какой тип стрима возвращает TcpClient.GetStream(). Тип стрима - NetworkStream.
2. Переходим по ссылке на NetworkStream и спускаемся к секции Thread Safety - она есть у всех классов, это стандартный элемент документации. Там написано:
Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.
Т.е. сказано, что потокобезопасными являются только статические методы. Эта фраза встречается у большинства классов, т.к. большинство не проектировались специально для многопоточной работы. Вот concurrent-коллекции - это другое дело, у них так и написано (очередь):
All public and protected members of ConcurrentQueue are thread-safe and may be used concurrently from multiple threads.
Что логично, т.к. в межпотоковых блокировках весь смысл этой очереди, в отличие от обычной.
Учтите, что тот факт что только одним потоком вы читаете, а другим пишете, вовсе не значит, что они не будут мешать друг-другу. Например, и чтение и запись могут менять какие-либо внутренние указатели и индексы (номер текущего байта или сколько еще непрочитанных байт осталось), о которых вы и знать не можете. Поэтому всегда идем в документацию и проверяем, что там.

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

www.vmime.org
libmailcore.com

Если эти либы слишком тяжелые, проще взять boost.asio и самому работать по нужному протоколу.

class Obj { }
class Collection : Obj
{
   private List<Obj> items;
}
class Item : Obj { }

паттерн называется Компоновщик. Можно начать с википедии.

Плюс в том, что структуру и интерфейс модели в больших проектах не хочется делать зависимым от вьюхи в какой бы ни было степени. Вот смотрите, у вас например есть атрибут Display или StringLength - зачастую такие вещи излишни в бизнес-модели. С этой моделью, возможно, будет работать код, вообще не имеющий ничего общего с выводом данных пользователю, например какой-нибудь фоновый бот или сборщик статистики. Или, что чаще встречается, с этой же моделью будет работать совершенно другое представление - например одна вьюха у вас "для всех", т.е. для клиентов, к примеру, интернет-магазина, а другая - для работников, которые обслуживают заказы. И у них те же данные о клиентах и заказах будут выводиться совершенно иначе.
Поэтому как правило удобнее иметь промежуточный слой в виде ViewModel, которая "приближает" данные общей модели к конкретному представлению. Я, например, часто делаю именно во ViewModel различные вычисляемые свойства, которые нужно вывести куда-нибудь, да хоть в таблицу. Т.е. в бизнес-модели у меня расход топлива на километр, и пройденный путь, а во ViewModel помимо этого еще и общий расход топлива на текущий момент времени (который, разумеется, рассчитывается на лету).