Могу ли я контролировать расположение пользовательских настроек .NET, чтобы избежать потери настроек при обновлении приложения?

Question

Я пытаюсь настроить местоположение файла user.config. В настоящее время он хранится с хешем и номером версии

%AppData%\[CompanyName]\[ExeName]_Url_[some_hash]\[Version]\

Я хочу, чтобы он был не зависим от версии приложения

%AppData%\[CompanyName]\[ProductName]\

Можно ли это сделать и как? Каковы последствия? Потеряет ли пользователь свои настройки от предыдущей версии после обновления?

Answer 1

Я хотел бы добавить этот цитируемый текст для справки, когда у меня возникнет эта проблема в будущем. Предположительно, вы можете указать инфраструктуре ApplicationSettings скопировать настройки из предыдущей версии, вызвав Upgrade :

Properties.Settings.Value.Upgrade();

С FAQ по настройкам клиента сообщение в блоге: ( архив )

В: Почему в пути user.config указан номер версии? Если я разверну новую версию своего приложения, не потеряет ли пользователь все настройки, сохраненные в предыдущей версии?

A: Есть несколько причин, почему Путь к user.config зависит от версии.

(1) Для поддержки параллельного развертывания разных версий приложение (вы можете сделать это с Clickonce, например). это возможно для другой версии приложение иметь разные настройки сохранено

(2) При обновлении приложение, класс настроек может были изменены и не могут быть совместимо с тем, что спасено, что может привести к проблемам.

Однако мы упростили обновить настройки с предыдущего версия приложения к самый последний. Просто позвони ApplicationSettingsBase.Upgrade () и он получит настройки из предыдущая версия, которая соответствует текущая версия класса и магазина их в текущей версии файл user.config. У вас также есть возможность переопределить это поведение либо в вашем классе настроек или в реализация вашего провайдера.

В: Хорошо, но как мне узнать, когда позвонить обновить?

A: Хороший вопрос. В Clickonce, когда Вы устанавливаете новую версию своего application, ApplicationSettingsBase обнаружит это и автоматически обновить настройки для вас в точке Настройки загружены. В non-Clickonce случаев, нет автоматического обновления - Вы должны позвонить Обновите себя. Вот одна идея для определения, когда позвонить Upgrade:

Иметь логическую настройку под названием CallUpgrade и дать ему значение по умолчанию значение истины. Когда ваше приложение запускается вверх, вы можете сделать что-то вроде:

if (Properties.Settings.Value.CallUpgrade)
{
   Properties.Settings.Value.Upgrade();
   Properties.Settings.Value.CallUpgrade = false;    
}

Это гарантирует, что Upgrade () звонил только в первый раз приложение запускается после новой версии развернут.

Я ни на секунду не верю, что это могло бы действительно сработать - Microsoft никак не могла бы предоставить такую ​​возможность, но метод все тот же.

Answer 2

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

Что касается второго вопроса, это зависит от того, как вы развернете приложение. Если вы развертываете через MSI-файл, то в свойствах проекта установки (из которых построен MSI-файл) есть два хэша: «код обновления» и «код продукта». Они определяют, как можно установить msi, а также обновлять, перезаписывать или устанавливать помимо любой другой версии того же приложения.

Например, если у вас есть две версии вашего программного обеспечения, и у них разные коды «обновления», то для окон они представляют собой совершенно разные части программного обеспечения, независимо от названия. Однако, если код «обновления» такой же, но код «продукта» отличается, тогда, когда вы попытаетесь установить 2-ю версию MSI, он спросит вас, хотите ли вы обновить, и в это время он должен скопировать значения из старый конфиг в новый конфиг. Если оба значения одинаковы, а номер версии не изменился, то новый конфиг будет в том же месте, что и старый конфиг, и ему ничего не нужно будет делать. Документация MSDN

ClickOnce немного отличается, потому что он основан на версии и пути URL ClickOnce, однако я обнаружил, что, пока вы продолжаете «Публиковать» в том же месте, новая версия приложения будет продолжаться использовать существующий конфиг. ( ссылка на то, как ClickOnce обрабатывает обновления )

Я также знаю, что есть способ объединить конфиги вручную во время установки MSI с помощью пользовательских сценариев установки, но я не помню точных шагов для этого ... (см. эту ссылку как это сделать с помощью web.config)

Answer 3

Файл user.config хранится по адресу

c:\Documents and Settings>\<username>\[Local Settings\]Application Data\<companyname>\<appdomainname>_<eid>_<hash>\<verison>

<c:\Documents and Settings> - каталог пользовательских данных, не в роуминге (локальные настройки выше) или в роуминге.
<username> - это имя пользователя.
<companyname> - это значение CompanyNameAttribute, если оно доступно. В противном случае игнорируйте этот элемент.
<appdomainname> - это AppDomain.CurrentDomain.FriendlyName. Обычно по умолчанию используется имя .exe.
<eid> - это URL, StrongName или Path, основанные на доказательствах, доступных для хэша.
<hash> - это хэш доказательств SHA1, полученный от CurrentDomain, в следующем порядке предпочтения:
1. StrongName
2. URL:
Если ни один из них недоступен, используйте путь .exe.
<version> - это параметр AssemblyVersionAttribute для AssemblyInfo.

Полное описание здесь http://msdn.microsoft.com/en-us/library/ms379611.aspx

Answer 4

(я бы добавил это в качестве комментария к ответу @ Amr, но у меня еще недостаточно представителей, чтобы сделать это.)

Информация в статье MSDN очень ясна и, кажется, все еще применима. Однако не следует упоминать, что хэш SHA1 записывается в кодированной базе 32, а не в более типичную базовую 16.

Я полагаю, что используемый алгоритм реализован в ToBase32StringSuitableForDirName, который можно найти здесь в справочном источнике Microsoft .