Алексей Кулаков

берете, создаете CancellationTokenSource, далее из него берете токен. его можно передать в таск. но сам токен не остановит выполнение таска. он так сказать пробрасывает информацию о том что была запрошена отмена операции внутрь таска. далее вы в своем коде можете проверить отменили ли задачу и прекратить ее исполнение. на кнопку отмены загрузки нужно повесить вызов CancellationTokenSource.Cancel() но именно того сорца что вы создали раньше для токена переданного в загрузку файла.

Разбиваем. Ничего плохого не вижу, все зависит от класса, как и везде главное не переборщить.

У нас есть классы, которые берут на себя много работы и, соответственно, в них много кода. его нужно как-то группировать по функциям. тут либо делать region-ы либо распихать по файлам и обозначить класс как partial

приведу простой пример когда я бы разделил. есть класс, у него есть какие-то методы отвечающие за работу, свойства, поля и сравнительно большое количество event-ов. вероятность того что эти самые эвенты будут часто просматривать не очень велика, в основном смотрят методы потому что в них основная работа. соответственно чтобы эти эвенты глаза не мозолили их можно:
1) запихать в region и свернуть. но! это дело у кого-то будет свернуто у кого-то нет, при поиске по файлу регион, опять таки, может быть развернут и его опять нужно свернуть. неудобненько.
2) договориться убирать эти эвенты в самый конец файла. но! они же когда-нибудь могут понадобится и листать в конец не очень приятно.
3) сделать класс partial и переместить часть с эвентами в отдельный файл. в какой нибудь SuperAwesomeClass.Events.cs. что мы этим добьемся? расчистим основной файл от редко просматриваемых членов класса, группируем некий код по смыслу, получаем быстрый доступ к эвентам если нам понадобится в них заглянуть и они точно будут все и в одном месте.

но это лишь мое имхо.

Смотрите, я вижу две ситуации
1) Проект А это приложение то есть имеет расширение EXE. Проект Б это подключаемая библиотека то есть dll.
2) Проект А и проект Б это оба приложения то есть имеют расширение EXE. (предполагаю у вас именно так).

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

Давайте я вам немножко доп. инфы про .net отсыплю. Дело в том что в .NET и .exe и .dll файлы это сборки и они имеют практически идентичную структуру, различие только в том что в валидной .exe сборке обязательно есть этот самый метод MAIN.
я может сейчас взорву вам мозг, но проект приложения может использовать ссылки и на .dll и на .exe .net-сборки и я очень даже уверен что смогу зареференсить .exe сборку в проект .dll сборки. такие вот дела

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

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

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

У вас Items это List. Эта коллекция позволяет обращаться к элементам по индексу, то есть Items[0].asr. В чем проблема?

Там находятся кешированные данные, которые теоретически могут быть использованы заново. На просторах интернета нашлись упоминания о программе под названием RamMap. Она поможет определить ресурсы, загаживающие память. Кстати GC тут не причем, конечно если у вас код чтения не кривой и все высвобождается корректно. За кешированные в памяти данные ведь отвечает ОС, а не GC.

а чем вам Form.ShowDialog() не угодил?

"Имеется возможность использовать этот метод для отображения модального диалогового окна в приложении. При вызове этого метода код, следующий за ним, не выполняется до тех пор, пока диалоговое окно не будет закрыто." (с) MSDN
Как раз то что вам нужно, не?