VoidVolker

• Самое ближайшее и доступное в вашем случае - GitHub Actions
  
• Чуть более сложно, но больше гибкости и автономности - GitLab PipeLines (можно даже у себя захостить сервер)
  

Использовать стандартные паттерны типа MVC и MVVM. Для большинства приложений этого достаточно. Если приложение более сложное, то оно делится на компоненты в виде, опять же, стандартных библиотек и приложения/приложений.

Смотрите свойства Margin и Padding у самих контролов и их контейнеров.

почему писать GUI на C++/CLI не самая лучшая идея?

Потому что на шарпе c WPF/MAUI проще.

#if DEBUG
        server = "test";
#else
        server = "prod";
#endif

WindowsForms использует очень древний и устаревший GDI+ - сегодня его использовать имеет смысл только если нужна поддержка Windows XP (либо еще каких-то окаменелостей). Во всех остальных случая лучше использовать WPF или MAUI - там нет лагов и тормозов. Если же хочется ускорить формы, то ищите по теме "speedup/boostup gdi windowsforms" - там надо добавить несколько дополнительных флагов при создании окна и, ЕМНИМ, включить двойную буферизацию. На SO есть все решения. Но, некоторые тормоза все же будут. Если хочется красиво запустить приложение, то при запуске надо создавать окно в скрытом виде, затем ждать пока инициализируются остальные компоненты и только потом уже показывать само окно. Если нужна производительная сложная анимация - то про формы лучше забыть и сразу перекатываться в WPF/MAUI. В крайнем случае можно создать компонент на WPF и использовать его в формах: я так делал или наоборот, когда надо было использовать древнее легаси WinAPI, но в современной красивой обертке с нужными фичами. На счет интеграции MAUI и форм не подскажу.

IEnumerable - интерфейс, а List - класс, реализующий данный интерфейс. Любой класс может реализовывать несколько интерфейсов. Правильнее объявлять как есть - т.е. List, а там где, где нужен конкретный интерфейс/класс - просто делать каст. Обычно не требуется, т.к. IDE/компилятор еще стадии написания/компиляции кода проверяет наличие нужного интерфейса в передаваемом объекте. Соответственно, если ваш конструктор просит IEnumerable, но не разрешает List - проверяйте точнее, что именно нужно конструктору, т.к. если все правильно делать - то List он должен принимать.

Нет, оно там просто не нужно - достаточно просто правильно структурировать приложение. В WF вполне достаточно просто разделить логику приложения и логику самого интерфейса. Нужен нестандартный контрол со своим поведением? Отпочковываем класс от Control и вперед. Логика самого интерфейса вполне нормально живет в самих классах элементов управления (в терминах MVVM это два в одном View + ViewModel). Например, реальный случай из практики: запилил WF приложение по выданному дизайну - его потестили и почти сразу дизайнер нарисовал полностью новый дизайн; ввиду увеличения фишечек, рюшечек и всего остального (а так же тормозов древнего легаси наследия WF, конечно же) - я просто перенес файлы с логикой из WF проекта в WPF проект в модели и запилил новый GUI на WPF.

Если памяти хватает - создать массив нужного размера и далее его сохранять в нужный формат в файл. Имеет смысл поискать либы для работы с большими файлами. Либо писать самостоятельно. Про GDI вам уже сказали, что он не поддерживает большие файлы - там просто древний легаси код. Если памяти не хватает - работать с пикселями в потоковом режиме или с небольшими блоками, зависит от того, что надо делать с изображением.

C 95% вероятностью отсутствующие библиотеки, конфиги, зависимости или сам .Net на другой машине, а в коде приложения нет проверок/обработки ошибок загрузки библиотек/конфигов/зависимостей. Проверить список зависимостей приложение и их присутствие на целевой машине, добавить обработку не обработанных исключений и логирование запуска приложения на разных этапах для понимания в какой момент происходит ошибка/падение.

Например:

class MyClass
{
    ...
    static class Strings
    {
        public static string str1 = "string 1";
    }
}

Или просто вынести в отдельный файл.