Илья Голец

1. Запустить не из студии, а из каталога bin, чтобы убедиться, что студия не влияет на это.
   
2. Установить у себя и запустить
   
3. Сравнить архитектуру процессора
   
4. Сравнить каталог с установленной программой на целевой машине и каталог bin на девелоперской
   
5. Посмотреть EventLog на целевой машине, там может быть ругань на отсутствие файла или на ошибку доступа
   
6. В program.cs весть код main() обуть в try-catch и показывать содержимое эсепшена на экран, или писать в темп каталог.
   

1. Не установлен .net нужной версии
   
2. Запуск сборки х64 на х32
   
3. Не установлены сторонние библиотеки
   
4. Не доставлена одна из сборок
   
5. Один из файлов в процессе сборки установщика побился
   
6. Что-то прописано в конфиге, но требует настроки на целевой машине (строка подключения, например)
   
7. Недостаточно доступа у юзера на целевой машине
   

1. DataTrigger может биндится через конвертер, соответственно, будет вызываться код конвертера с передачей данных из модели. Пример https://itecnote.com/tecnote/c-wpf-calling-method-...
   
2. EventTrigger может запускать TriggerAction. Можно написать свой TriggerAction и этот код будет вызываться по триггеру. Пример https://putridparrot.com/blog/a-simple-wpf-trigger...
   
3. Ну и по-простому можно триггером выставлять свойство контрола, а изменение свойства обрабатывать обработчиком.
   

1. WPF немного адаптирован для MVVM, но это не обязательно — масса примеров в родной документации не использует никакого MVVM. Так что я бы не связывал выбор использования MVVM с WPF.
   
2. Есть готовые библиотеки для WinForms, которые умеют делать легкий MVVM. Лично я, например, работал с DevExpress и на мой взгляд, из коробки он дает даже больше, чем WPF (например, есть встроенные сервисы работы с попап окнами). Так что использовать MVVM на WinForms не сложнее, чем на WPF.
   
3. И раз мы отделили вопрос MVVM от WPF/WF, нужно принципиально решать вопрос использовать ли MVVM в конкретном проекте.
   
4. И, собственно, вопрос использование MVVM имеет плюсы и минусы. Плюсы — сопротивление хаосу при массированных изменениях кода, уменьшение человеческого труда при тестировании. Минусы — больше кодинга (накладные расходы на раздельную реализацию VM + юнит-тесты), не устраняет ручное тестирование до конца. Использовать MVVM без юнит-тестов смысла особо не вижу — кодить больше, выгоды никакой.
   

set MyKey="My key from Environment"
set Position__Title=Environment_Editor
set Position__Name=Environment_Rick
dotnet run

// из public class Startup
        public void ConfigureServices(IServiceCollection services)
        {
            services. Configure<PositionOptions>(Configuration.GetSection(
                                                PositionOptions.Position));
            services.AddRazorPages();
        }

// из кода, который обращается к настройкам
    public class PositionOptions
    {
        public const string Position = "Position";

        public string Title { get; set; }
        public string Name { get; set; }
    }

        public Test2Model(IOptions<PositionOptions> options)
        {
            _options = options.Value;
        }

        public ContentResult OnGet()
        {
            return Content($"Title: {_options.Title} \n" +
                           $"Name: {_options. Name}");
        }

1. сделать класс ApiConfig (по образцу PositionOptions из примера выше)
   
2. в Startup вызвать services. Configure, передав данные класса ApiConfig
   
3. в коде, который дожен работать с ApiConfig запросить в конструкторе IOptions<ApiConfig>
   

var title = Configuration["Position:Title"];
            var name = Configuration["Position:Name"];