VoidVolker

Ну, очевидно же, что вот на эту вашу фантазию:

Command="Exitfoo"

Даже сама студия прям сразу же пишет в редакторе, что данное значение тут недопустимо.
RTFM:

1. Windows Desktop / WPF/ Advanced / Commanding Overview: https://learn.microsoft.com/en-us/dotnet/desktop/w...
   
2. Далее смотрим что это за свойство — CommandBinding.Command Property: https://learn.microsoft.com/en-us/dotnet/api/syste...
   
3. И далее открываем список допустимых значений данного свойства — ApplicationCommands Class: https://learn.microsoft.com/en-us/dotnet/api/syste...
   

Кроме того, ваш хоткей Ctrl+W для выхода из приложения является контр-интуитивным и использовать такой хоткей для выхода из приложения нельзя, т.к. этот хоткей традиционно используется для закрытия вкладок. Кроме того, винда имеет стандартный хоткей Alt+F4 для закрытия окна или выхода из приложения.

Для тех, кто в танке или кому просто интересно, объясню почему ошибка происходит в конвертере. А происходит следующее: парсер после разбора XML, видит значение в поле Command — т.к. это всё XML, то там строка и из этой строки надо сделать конвертацию в тот тип, который указан в классе CommandBinding для свойства Command, а именно в тип, реализующий интерфейс ICommand.
У класса Window через цепочку наследования в предках есть класс UIElement, который и реализует свойство привязки команд через коллекцию:

public class System.Windows.UIElement : Visual, IInputElement, IAnimatable
{
    public CommandBindingCollection CommandBindings { get; }
}

И соответственно тип в этой коллекции:

public class System.Windows.Input.CommandBinding
{
    public ICommand Command { get; set; }
}

И вот дальше в работу включаются конвертеры. Есть список конвертеров, а в каждом конвертере есть методы, которые сообщают что во что они могут конвертировать. И парсер по очереди опрашивает эти самые конвертеры. И вот какой-то конвертер как раз умеет конвертировать из строки в нужный тип, который и реализует интерфейс ICommand, а именно в класс System.Windows.Input.RoutedUICommand(src). Соответственно список этих команд находится в статическом классе System.Windows.Input.ApplicationCommands, среди которых и происходит поиск нужной команды. Костыльно? Да, костыльно, ну хотя бы работает.

Многое зависит от внутренней архитектуры решения, зависимостей, а так же целей и задач, которые вы этим процессом хотите решить. Если вся логика разделена на отдельные модули, то портировать проект на более современные версии .Net будет не очень больно. Но всё равно будет больно. Например, если бизнес-логика и интерфейс чётко разделены — то после разработки нового интерфейса на WPF/Avalonia внедрить всю эту логику будет относительно несложно. А вот если там всё в одной куче — процесс портирования равносилен разработке решения с нуля. Если бюджет позволяет и это решит какие-то ваши текущие задачи — то он вполне имеет смысл быть. Обычно в WinForms всё в одной куче и для новой платформы надо просто всё переписать с нуля. В WPF и иже с ним обычно используют паттерн MVVM, а не MVP. Так что внедрять MVP в WinForms проект не имеет особого смысла — лучше сразу MVVM с прицелом на полноценный переход на WPF. При условии, конечно, дальнейшего развития проекта и наращивания функционала. Если же глобальная цель проекта просто исправление багов и иногда правка функционала — то нет никакого смысла что-то делать. Разве что рефакторинг и детальное документирование, если всё не очень там хорошо с этим.

string. У вас файл текстовый — вот и используйте как есть.

Получить список интерфейсов объекта из его типа и проверить есть ли среди них нужный вам универсальный интерфейс:

if (item != null
    && item.GetType().GetInterfaces().Any(
        i => i.IsGenericType
        && i.GetGenericTypeDefinition() == typeof(IEnumerable<>))
    )
{
    IEnumerable<object> collection = (IEnumerable<object>)item;
}

У вас приложение на платформе .Net Framework (версия 4.8.1 или более ранняя) и там вот такой вот мастер публикации. А вот для более новых платформ — .Net 6.0, 8.0 и 9.0 мастер другой и с другими опциями. Там у него конфигурация в виде стандартного xml файла. Если вы хотите использовать более новый мастер — то вам надо мигрировать ваше приложение на более новый .Net.

"Правильность" зависит от точки зрения, требований, ограничений и прочих особенностей решения. Ваш код решает вашу проблему? Удовлетворяет вашим требованиям, предъявляемым к нему? Значит всё отлично. Если нет - то тут уже надо думать и искать более правильное решение по конкретным критериям конкретного проекта.

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

public class MyForm : Form
{       
    protected override void WndProc(ref Message m)
    {           
        if(m.Msg == WM_MOUSEWHEEL) 
        {
            // ...
            return;
        }; 
        base.WndProc(ref m);
    }
}

- int izgib = random.Next(izi_ot, izi_do);
+ double izgib = random.Next(izi_ot, izi_do)/10.0;

public System.Windows.Media.ImageSource Source { get; set; }

https://learn.microsoft.com/en-us/dotnet/api/syste...
Ну и у вас в коде же правильное решение:

TestImage2.Source = new BitmapImage(LoadedUri);

Т.е., вам надо конвертер не в Uri, а в тип BitmapImage. Ну или просто завести сразу свойство нужного типа.

Кроме того, вот тут у вас ошибка во втором параметре конвертера, который противоречит касту:

var LoadedUri = (Uri)stringToUriConverter.Convert(a, typeof(BitmapImage), null, CultureInfo.CurrentCulture);

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

DataGrid -> Properties -> AutoGenerateColumns
А вообще, дата-грид и многие другие сложные контролы в WPF - то ещё веселье. Посмотрите в сторону AvaloniaUI. Ну а если всё же захотите сделать что-то чуть сложнее стандартных примеров из мана со стандартными контролами - то их шаблоны всё равно придётся переделывать, а местами реализовывать тот же функционал, но работающий правильно, а не в стиле индусов. Вот как-то так, например: GridTable.cs - таблица на базе обычного Grid с добавленными свойствами шаблонов для заголовков и ячеек, а так же своим движком для рендернинга таблицы (строк, столбцы, заголовки).

Learn / Windows / Apps / Win32 / API / Keyboard and Mouse Input / Winuser.h / GetKeyState():
https://learn.microsoft.com/en-us/windows/win32/ap...

1. Да, надо. Нет, все исключения в Main поймать нельзя.
   
2. Есть несколько вариантов:
   1. Сообщение в стандартном WPF контроле в рамках основного окна (типа стандартного сообщения или всплывающего контрола).
      
   2. Стандартное WinAPI сообщение.
      
   3. Отдельное окно с WPF контролом и деталями сообщения.
3. Да, вполне нормальный вариант.
   

В целом же, стандартный подход выглядит примерно так:

• Создаём несколько категорий исключений для разных ситуаций (условно - диск, приложение, загрузка, скачивание, сеть и т.п.)
  
• В каждой категории создаём несколько типов исключений, наследуя их от класса Exception и указывая параметры исключений
  
• На верхнем уровне ловим исключения, для каких-то определённых типов исключений можно добавлять отдельные ветки
  
• В обычных условиях просто выкидываем исключение, которое будет поймано на верхнем уровне
  
• В нестандартных условиях ловим на месте или показываем сообщение об ошибке с ожиданием
  

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

Реальный пример базового класса для исключения с локализацией:

    /// <summary>
    /// Localized exception
    /// </summary>
    /// <param name="stringId">i18n string Id</param>
    /// <param name="args">String arguments for format</param>
    public class I18nException(string stringId, object[] args)
        : Exception(
            string.Format(
                I18n($"{ExceptionId} {stringId}"),
                args))
    {
        public readonly object[] Args = args;
        public readonly string StringId = stringId;
        private const string ExceptionId = "Exception";
    }

I18n(string str) - функция для получения локализованной строки для текущего языка приложения.
Ну и далее наследуем свои исключения от этого базового типа:

    public class ElementNotFoundException(Type type, string name)
        : I18nException(
            "Element not found",
            [type.FullName, name]
        )
    {
        public readonly string ElementName = name;
        public readonly Type ElementType = type;
    }

(тыц).

Сравнить координаты и размеры окна с координатами и размером текущего экрана.

Просто создаёте кроссплатформенный .Net 9 проект и добавляете профили публикации для разных ОС. Далее под виндой делаете сборку для винды, а под линуксом соответственно делаете сборку для линукса с использованием этих самых профилей. Если вам нужна графическая оболочка - то отличным выбором будет что-то типа Avalonia. Для платформенно-зависимого кода используйте стандартные директивы препроцессора. Если вы хотите для разных платформ использовать разные фреймворки/библиотеки, есть много кода для разных платформ или сложные зависимости, то в этом случае удобнее сделать три проекта: по отдельному проекту для каждой платформы и третий зависимый проект в виде библиотеки с общим для всех платформ кодом.

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

Да, так оно и работает.

или есть способы попроще

Проще уже некуда.

Именно массив с любыми типами вот так можно сделать:
object[] foo = { "Abc", 123 };
А на картинке у вас уже массив объектов со своими свойствами (в соседнем ответе пример привели уже).

Есть поля и есть свойства. Доступ к свойству осуществляется через методы - получения, записи, добавления или вычитания свойства. У полей нет отдельных методов доступа - используется только стандартный механизм доступа. RTFM:
classes and structs -> fields
classes and structs -> properties