Как разрешить редактируемые файлы конфигурации .Net, созданные с помощью MSIX?
Я пытаюсь помочь перенести службу .Net на более современную версию .Net (возможно, Core) и использовать установщик MSIX. Приложение имеет несколько конфигурационных файлов, сгенерированных компилятором (в исходном коде это app.config, но при компиляции они становятся *.exe.xml), они устанавливаются в Program File рядом с двоичными файлами, а также вспомогательным приложением с графическим интерфейсом и приложением. сам может изменить их, чтобы изменить поведение службы (порт, ip, сертификат tls и т. д.).
Запись в C:\Program Files\WindowsApps\имя_пакета не разрешена. Запись в C:\Program Files\WindowsApps\имя_пакета не разрешена.
Проблема, с которой я столкнулся, заключается в том, что установщик MSIX делает так, что файлы в изолированной версии Program Files не могут быть записаны (см. выше). Это означает, что это приложение не может быть настроено, поэтому я пытаюсь выяснить не только, как сделать приложение снова настраиваемым, но и как Windows хочет обрабатывать конфигурацию приложения.
Сейчас кажется, что есть два общих подхода к этому:
- записать данные конфигурации в папку AppData/local учетной записи службы
- попробуйте имитировать поведение
/etc/Myserviceв другой папке. (имеется в виду локальный общесистемный каталог, в котором хранятся данные конфигурации для службы)
Если вы предлагаете № 1, пожалуйста, ответьте на следующие дополнительные вопросы:
- Как мне переместить файлы конфигурации приложения в каталог файлов конфигурации пользователя
- как администратор с обычной учетной записью может изменить файл конфигурации в папке AppData учетной записи службы с помощью упомянутого вспомогательного приложения с графическим интерфейсом? (нужно ли им разрешить доступ к рабочему столу для учетной записи службы, войти в систему и запустить графический интерфейс)?
Если вы предлагаете № 2:
- Где бы вы предположили, что этот каталог существует (в частности, где это позволит MSIX)?
- Как сообщить приложению .Net, что файлы не рядом с ним? Могу ли я просто использовать AppData.CurrentDomain.SetData?
Редактируемые файлы конфигурации никогда не хранятся в папке приложения, будь то Program Files или где-либо еще, где хранятся приложения UWP. Во всех случаях приложения должны хранить свои редактируемые данные под %APPDATA% или %LOCALAPPDATA% для общих настроек или %USERAPPDATA% для пользовательских данных. Фактический путь к специальной папке можно получить с помощью Environment.GetFolderPath
Это означает, что ничего не изменилось. Ни одно приложение не может быть настроено путем перезаписи его exe.config для начала. Даже приложения, которые так думали, были перенаправлены самой ОС. Поскольку вы используете ASP.NET Core, вы можете легко хранить файлы настроек в любом месте и заставлять их переопределять настройки, хранящиеся вместе с приложением.
Ответы 1
Что ж, служба, работающая от системной учетной записи, одинакова для всех пользователей, поэтому я бы сказал, что CommonApplicationData — лучшая папка для хранения ее настроек, а не appdata. Эта папка легко доступна как для вашей службы, так и для любого администратора, которому необходимо развернуть настраиваемый файл конфигурации.
В AppData вы должны хранить только фактические пользовательские файлы (такие как файлы или настройки, сгенерированные действиями, предпринятыми внутри вашего приложения конкретным пользователем — таким образом, разные файлы для разных пользователей).
Теперь во второй части вам нужно настроить свой код для загрузки файла конфигурации из пользовательского пути, а не искать его рядом с EXE. Я не эксперт по .NET, но после быстрого поиска я нашел это:
Современный подход к развертыванию настроек приложений
Что мне непонятно, так это то, как ваши клиенты используют вспомогательный инструмент с графическим интерфейсом для настройки файла конфигурации. Это просто инструмент, который используется кем-то из ИТ-отдела для создания файла конфигурации, а затем он копирует этот файл и развертывает его на компьютерах конечных пользователей с помощью файла MSI/MST (или с помощью другого пользовательского метода развертывания). )?
Если ваше приложение развернуто только ИТ-специалистами, вы можете попробовать другое более простое (и гораздо более элегантное) решение для предоставления ему пользовательского файла конфигурации, которое на самом деле не требует каких-либо изменений кода.
Вы по-прежнему можете оставить файл конфигурации рядом с EXE в ProgramFiles и поручить ИТ-командам, которые развертывают приложение, использовать Пакет модификации MSIX для развертывания пользовательского файла конфигурации, созданного помощником с графическим интерфейсом. (проверьте приведенную выше ссылку для примера - с видеоверсией в конце статьи).
Примечание. ИТ-специалисты могут использовать несколько бесплатных или платных инструментов для создания пакетов модификаций MSIX.
Конечно, ваш вспомогательный инструмент с графическим интерфейсом по-прежнему должен создавать этот настроенный файл конфигурации в папке, где это разрешено, поскольку он больше не может писать в ProgramFiles. Так что на самом деле вам нужно немного изменить свой код и в этом сценарии.
.NET Core не имеет файла .config, он может загружать настройки из нескольких поставщиков (включая базы данных, переменные среды и т. д.), хранящиеся по любому пути, доступному исполняющей учетной записи. Хранить данные в CommonApplicationData теперь так же просто, как использовать правильный путь. Провайдеры могут переопределять предыдущие настройки, поэтому никаких преобразований или настроек не требуется.
@PanagiotisKanavos — эта конфигурация обрабатывает все, что обрабатывается AppDomain API для каждой версии .Net?
@LiamKelly, это не имеет значения, потому что вы не должны пытаться писать exe.config в первую очередь. Кроме того, в ASP.NET Core нет файлов .config. Вам не нужно ничего изменять, просто сохраните дополнительные настройки в доступном для записи месте и убедитесь, что вы загружаете их после поставщиков, которые вы хотите переопределить. Учитывая значения по умолчанию (appsettings.json, appsettings.{env}.json, переменные evn, командная строка), простое использование AddJsonFile, указывающего на файл JSON в CommonApplicationData, может переопределить предыдущие настройки. Так же, как appsettings.Production.json переопределяет appsettings.json
Это не про MSIX. Файлы приложения не должны быть редактируемыми, независимо от того, хранятся ли они в
Program Filesили где-либо еще, где хранятся приложения UWP. Windows применяет это с 1990-х годов, делаяProgram Filesдоступным только для чтения. В более поздних версиях попытки некорректно работающих приложений туда записать перенаправляются в другие папки.