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

Теоретически, раз вы создаете форму в том же потоке, в которым с ней работаете - то все нормально, другой вопрос - зачем это делать и чего вы этим добиваетесь. В 98% GUI-приложений весь интерфейс находится в одном потоке и все работает замечательно (если открывается модальное окошко или диалог, оно просто крутит свой собственный цикл сообщений), а вот как раз другие потоки нужны для проведения длительных вычислений и операций ввода-вывода, чтобы GUI-поток не останавливался и мог спокойно и дальше ловить мессаджи от операционки на перерисовку и пользовательские действия. Так что если это не эксперимент в вакууме, то нужно основательно подумать, зачем вам такие финты - управлять несколькими гуевыми потоками нужно очень аккуратно.

stackoverflow.com/questions/1033841/is-it-possible...

Годится для небольшого количества элементов. Пропишите у ListView: ScrollViewer.CanContentScroll="False"

Ну вот толковые в принципе ответы на SO: stackoverflow.com/questions/4279185/what-is-the-us..., посмотрите, и скажите что конкретно непонятно.

Сейчас, в эпоху онлайн-сервисов, даже десктопные приложения частично работают с веб-службами и прочими интернетами, так что некоторые серьезные производители ПО уже начинают забивать на защиту десктопного приложения, ограничиваясь только проверками на стороне сервера при работе с сетевым функционалом (ну не знаю, например заливка файла в облако). Конечно, это пока не для всех подходит, но имеет смысл с учетом того что не ломаются только малопопулярные приложения (т.к. не интересуют взломщиков), а любые нормальные клиенты будут покупать продукт (на Западе вообще другой менталитет, люди считают работу ПО не по лицензии таким же воровством, как и украденный кошелек). Код на C++ тоже вполне себе неплохо дизассемблится тем, у кого есть опыт. Да, исходник восстановить гораздо сложнее, даже невозможно, но это и не нужно - все ломается в каком-нибудь OllyDbg по ассемблерному коду.
Кстати, Word и Photoshop это скорее "коммерческое" ПО, энтерпрайзом обычно называют всякий внутренний софт (банковские системы, всякие автоматизаторы, генераторы отчетов), и там C# не просто используется, а конкрурирует только с джавой. WPF и прочие технологии как раз для такого софта и создавались. Если хотите примеры продаваемого ПО на шарпе: ну вот хотя бы Citavi - вполне серьезный софт для референс-менеджмента (управление библиографией и ссылками в научной деятельности). Все на шарпе, использует кучу библиотек, при этом вполне себе стоит денег.

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

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

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

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

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

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

По ссылке что вы привели упоминается ProtectedConfigurationProvider, который находится в неймспейсе System.Configuration и вроде как прямого отношения к ASP.NET не имеет. Вы уверены что нельзя его использовать в вашем случае?

> Объект, работающий с SerialPort находится в отдельном потоке?

Цитирую из https://msdn.microsoft.com/en-us/library/system.io... :

The DataReceived event is raised on a secondary thread when data is received from the SerialPort object. Because this event is raised on a secondary thread, and not the main thread, attempting to modify some elements in the main thread, such as UI elements, could raise a threading exception. If it is necessary to modify elements in the main Form or Control, post change requests back using Invoke, which will do the work on the proper thread.

А вообще, если есть еще какая-то логика обработки данных, приходящих из порта, то лучше вызывать ее в ивенте DataReceived, и уже в ней, после необходимой обработки, отправлять более высокоуровневые сообщения в GUI-поток через какую-нибудь очередь сообщений, например организованную с помощью ConcurrentQueue. Тогда ваш GUI-поток будет дергаться не по приходу пары байт, а тогда, когда вам самим это будет нужно. Но это уже архитектурный вопрос, который я вас советую продумать, если у вас не одноразовая лаба.

Никаких lock-ов в экшене не будет (если вы их сами туда не поставите), и не нужно им там быть. Дефолтовая фабрика контроллеров создает инстанс контроллера на каждый запрос, поэтому 99 пользователей одного ждать не будут. Если нужны подробности - ищите в гугле "asp.net mvc controller instancing", вываливается масса статей с которых можно начать разбираться.