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

StackOverflow https://stackoverflow.com/questions/621265

  •  05-07-2019
  •  | 
  •  

Вопрос

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

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

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

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

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

Это было полезно?

Решение

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

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

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

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

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

Другие советы

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

Properties.Settings.Value.Upgrade();

От Часто задаваемые вопросы по настройкам клиента Сообщение блога: (архив)

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

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

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

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

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

Вопрос:Хорошо, но как я узнаю, когда вызовать обновление?

А:Хороший вопрос.В Clickonce, когда вы устанавливаете новую версию вашего приложения, ApplicationSittingSbase обнаружит его и автоматически обновляет настройки для вас при загрузке настройки точки.В случаях, не являющихся кликконами, автоматического обновления не существует - вы должны вызовать обновление самостоятельно.Вот одна идея для определения, когда вызовать обновление:

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

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

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

я ни на секунду не верю, что это действительно может сработать — Microsoft никак не может предоставить такую ​​возможность, но метод все равно существует.

Файл 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-адрес, строгое имя или путь, основанный на доказательствах, доступных для хеширования.
<hash> представляет собой хеш SHA1 данных, собранных из CurrentDomain, в следующем порядке предпочтения:
1.Строгое имя
2.URL-адрес:
Если ни один из них недоступен, используйте путь .exe.
<version> — это параметр AssemblyVersionAttribute объекта AssemblyInfo.

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top