VoidVolker

Это стандартный вид стандартных окон ОС Windows. Не нравится стиль - всегда можно нарисовать свой. WinForms использует древнее легаси API GDI+. Есть еще WPF, MAUI - там уже более новое. У вас какой именно вариант? Там немножко по-разному стили задаются. При желании можно нарисовать все что угодно. Ко всему есть подробнейшие мануалы в сети.

Скорее всего что-то не было установлено - дотнет, библиотеки, пакеты и другие зависимости. Сделайте отладочную сборку с выводом всех ошибок и запустите её на целевой машине и смотрите, что оно требует. Аналогично с дистрибутивом - убедитесь, что все зависимости включены в дистрибутив и устанавливаются как и куда надо. Тоже сделайте отладочную сборку и проведите отладку дистрибутива.

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

На самом деле именно так и делается - одни элементы скрываются, другие показываются по мере необходимости. Элементы группируются и скрываются пачкой. Для упрощения обычно группы дочерних окон просто размещают в окне-контейнере и скрывают этот контейнер целиком, а все его дочерние окна скроет сама ось. И второй вариант - создавать/уничтожать окна по мере необходимости. Но вот когда окон много - это увеличивает расход памяти и нагрузку на систему, а на медленных ПК большие и сложные интерфейсы могли даже тормозить. Это 20-25 лет назад все это было важно, а сегодня даже плюс-минус гигабайт никто на заморачивается.

Есть такая штука, называется "Декомпозиция задачи": вот это вам и надо сделать. Разбить свою задачу на несколько подзадач меньшего размера, а потом эти задачи разбить на подзадачи еще меньше и так далее, пока не станет все понятно. Затем следует объединить задачи в какие-то модули и логические блоки. И по шагам реализовывать нужный функционал. (И в очередной раз напоминаю, как вам уже неоднократно сказали: в вашем случае следует сделать карту игрового поля и основываясь на этой карте рисовать игровое поле - вы её сделали?)

Можно один исполняемый файл при условии отсутствия дополнительных зависимостей. Обычно студия зависимости кладет рядом в тот же каталог (release/debug), но в некоторых случаях не все зависимости копируются и тогда их надо ручками добавлять в конфиги. Для распространения приложения используется такая штука, как "дистрибутив" или установщик: все требуемые файлы упаковываются в один исполняемый и далее один этот файл распространяется. При запуске установщик распаковывает все файлы в указанный в его конфиге каталог и делает разные дополнительные действия типа создания ярлыков и прочее.

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

Например использовать свойства:

class Foo {
    private BarEnum _bar;
    public BarEnum bar {
        get { ... }
        set { ... }
    }
}

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

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

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

https://dev.mysql.com/doc/connector-net/en/connect...

---------------------------↓↓↓
"server=127.0.0.1;uid=root;pwd=12345;database=test"

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

Просто используйте WPF - там нет таких проблем с производительностью. У WinForms проблема с производительностью связана с использованием древнего GDI API. И, если хочется решить эту проблему - то в таком случае надо вручную писать рендеры для контролов. В данном случае это будет так: создать кастомный контрол и написать к нему кастомный рендер, который будет брать картинки и копировать их всех в один канвас/буфер, так же в самом этом контроле обрабатывать события пользовательского ввода. Плюс потребуется найти и применить дополнительные хаки для повышения производительности, такие как добавление специальных флагов стилей к окну, переписывание дополнительных методов в контролах и прочее. Проверено на личном опыте.

Если нужна глубокая кастомизация элементов управления — используйте WPF. Он и быстрее и гибче (требования к ОЗУ вырастут не сильно, по сравнению с формами).

Например:

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

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