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

Получается мне что то на подобии создания плагинов надо. При помощи какой технологии можно подобное сделать?

Managed Extensibility Framework (MEF)

У DataAdapter-а проставить SelectCommand в select * from Classes where Класс=5

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

А) Залогиньтесь через WebBrowser, возьмите куку, отдайте WebClient-у, скачайте файл;
Б) Разберитесь, как происходит авторизация на сайте, проведите её с помощью WebClient, получите куку, установите её в запрос на скачивание файла, скачайте файл.

Хромиум: CefSharp, Awesomium

Совет по общей структуре: в классе формы многовато данных. Понятно что с нее вы начинали все писать и из нее все вызывается, но время от времени нужно выделять группы данных/методов и выносить в отдельные классы или модули (в случае шарпа - это т.н. "статические" классы). Я по вашему коду разбил бы примерно так:
- хелперы для загрузки данных через прокси (и их автоматического переключения в случае ошибки - я правильно понял?): можно вынести в отдельный УмныйЗагрузчик, который заберет в себя всю логику пробивания к данным - перебор юзер-агентов, сбор статистики и т.д. Из этого умного загрузчика должны торчать: простой метод для загрузки нужного урла, простой метод для получения статистики, пусть даже текстом. На форме останется лишь присовение этой статистики 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-документацию, раз уж делаете комментарии к методам
- по возможности привыкайте пользоваться английским - довольно мало команд разработчиков могут себе позволить использование родного языка в коде.
Для начала достаточно. Прежде чем заморачиваться паттернами, ощутите на нескольких примерах как вообще пользоваться ОО-языком, что он вам дает и что требует от вас.

Вопрос действительно академический: вам нужно основательно разобраться с событийно-управляемой (event-driven) архитектурой приложений. Пожалуй, все современные графические подсистемы так или иначе построены на ней (а вообще - не только графические). И в первую очередь нужно понять, что выполнение действий в своем цикле без передачи управления обработчикам сообщений - неверный подход. Дело в том, что GUI-приложение, в отличие от консольного, для того чтобы "не зависать", должно постоянно выполнять некоторые действия помимо нужных для вашей задачи, а именно - перерисовываться, обрабатывать события клавиатуры и мыши и т.д. Изза того что ваша программа "крутится" в цикле, то все те стандартные обработчики событий, которые должны получать управление, не получают его. Поэтому, если нужно выполнять интенсивные вычисления в графическом приложении, нужно либо:
а) выполнять их в другом потоке - тогда получится сохранить структуру приложения и циклы, но встанет задача межпоточной передачи данных;
б) выполнять работу порционно, время от времени передавая управления обработчикам системных событий. Это т.н. вызов DoEvents, в разных API он разный, но суть одна и та же.

Конкретно для вашей задачи цикл на самом деле совершенно не нужен - вся анимация, какой бы они ни была, в современных приложениях (старые DOSовские игры не в счет) строится на таймерах и событиях их срабатывания. Поэтому вам нужно разобраться, как пользоваться в вашей среде таймерами и генерировать периодические события, и уже в обработчике события таймера делать label1.Text = "." , ".." , "..." в зависимости от того, какой "кадр" был предыдущий.