Повышенные права : файлы, установленные в %ProgramFiles%, будут только для чтения для обычных пользователей (а также администраторов,если вы не повышаете права через приглашение UAC ).Вы должны определить, что делает ваше приложение, для которого требуется доступ на запись к файлам, установленным в этой папке, или пытаетесь ли вы выполнить запись в HKLM в реестре, что вызовет ту же проблему (исключение в доступе отказано).Также возможно, что ваше приложение пытается сделать что-то, что требует определенных NT привилегий , доступных только для пользователей-администраторов - что требует повышения прав (привилегии отличаются от прав доступа - ACL - в том, что они распространяются на всю систему,и не «привязан» к объектам - например, «изменить системное время» - из-за отсутствия лучшего примера).
Переместить файлы : Есть несколько способов исправить эту проблему доступа (или обойти ее) , но немногие рекомендуются.Я бы предложил вам переместить файл настроек , который вызывает исключение, в профиль пользователя и сохранить там настройки с полным доступом к записи.Вы также можете применить пользовательские разрешения ACL к установленным файлам (см. раздел 6 в ссылке выше), но это не очень хорошая идея по многим причинам (безопасность, сохранение настроек и т. Д.)....).См. Ссылку выше для дальнейшего описания альтернатив (сохранение настроек в базе данных и доступ при запуске и другие подходы).
Контрольный список : Здесь общий контрольный список для проблем с запуском приложения .
Attach Debugger : я иногда использую один метод, чтобы установить отладку-binaries к %ProgramFiles% и затем сразу же выводят окно сообщения из последовательности запуска (если запуск вообще заходит так далеко).Затем я присоединяю отладчик Visual Studio к окну сообщения и запускаю интерактивную отладку из установленного продукта для проверки ошибок и исключений. Процедура описана здесь .
Отказ от ответственности : Хотя это и очевидно, следует отметить: никогда не использовать отладочные двоичные файлы для фактического выпуска .1) Совсем не законно, 2) не очень хорошая идея из-за прозрачности и возможности обратного инжиниринга отладочных двоичных файлов, и 3)исполняемые двоичные файлы среды отладки не будут существовать в блоках, не предназначенных для разработчиков (и не будут соблазняться статически связывать - если это возможно в режиме отладки)И наконец: может быть легко забыть перестроить с помощью двоичных файлов релизов, когда вы возитесь с такой отладкой.Это обязательно произойдет.
Сканирование зависимостей : существует ряд инструментов, которые можно использовать для поиска проблем с зависимостями, которые могут вызвать проблемы с запуском. Вот список инструментов сканирования зависимостей .Также можно проверить раздел " Просмотр модулей Visual Studio ".Я не уверен, что это представление покажет вам, какие файлы настроек используются (или только какие двоичные файлы загружены).
Некоторые ссылки :