Posso controlar a localização das configurações do usuário NET para evitar a perda de configurações na atualização do aplicativo?

Question

Eu estou tentando personalizar a localização do arquivo user.config. Atualmente ele é armazenado com um número de hash ea versão

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

Eu quero-o ser agnóstico para a versão do aplicativo

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

Isso pode ser feito e como? Quais são as implicações? Será que o usuário perder suas configurações da versão anterior após a atualização?

Answer 1

Para responder à primeira pergunta, você tecnicamente pode colocar o arquivo onde quiser, no entanto, terá de código-lo sozinho, como o local padrão do arquivo vai para é o primeiro de seus dois exemplos. ( link para como fazê-lo sozinho )

Quanto à segunda questão, isso depende de como você implantar o aplicativo. Se você implantar através de um .msi, então há duas hashes nas propriedades do projeto de instalação (que a MSI é construído a partir de), o 'código de upgrade' e o 'código do produto'. Estes determinam a forma como o msi pode ser instalado, e se upgrades, substituições ou instalações ao lado de qualquer outra versão do mesmo aplicativo.

Por exemplo, se você tem duas versões de seu software e eles têm códigos diferentes 'upgrade', em seguida, para janelas são completamente diferentes peças de software, independentemente do que o nome é. No entanto, se o código 'upgrade' é o mesmo, mas o código 'produto' é diferente, então quando você tentar instalar o 2º msi ele vai perguntar se você deseja atualizar, altura em que é suposto para copiar os valores do configuração antiga para uma nova configuração. Se ambos os valores são os mesmos, e o número da versão não mudou então a nova configuração será no mesmo local que a configuração antiga, e não terá que fazer qualquer coisa. Documentação MSDN

ClickOnce é um pouco diferente, porque a sua base mais fora da versão ClickOnce # e caminho de URL, no entanto eu descobri que, enquanto você continuar a 'Publicar' para o mesmo local a nova versão do aplicativo continuará para usar a configuração existente. (Ligação a como ClickOnce lida com as atualizações )

Eu também sei que há uma maneira de configurações mesclar manualmente durante a instalação do msi usando scripts de instalação personalizada, mas eu não me lembro exatamente os passos para fazê-lo ... (ver este link para saber como fazê-lo com um web.config)

Answer 2

Eu queria acrescentar este texto citado como uma referência para quando eu tenho esse problema no futuro. Supostamente você pode instruir a infra-estrutura ApplicationSettings para copiar configurações de uma versão anterior, chamando Atualização :

Properties.Settings.Value.Upgrade();

A partir Cliente Configurações FAQ post: ( Arquivo de )

Q: Porque é que existe um número de versão no caminho user.config? Se eu implantar uma nova versão do meu pedido, não será o usuário perde todas as configurações salvas pela versão anterior?

A: Existem algumas razões pelas quais os caminho user.config é a versão sensível.

(1) Para apoiar lado-a-lado de implantação de diferentes versões de um aplicação (você pode fazer isso com Clickonce, por exemplo). Isto é possível para versão diferente do aplicativo para ter configurações diferentes salvo fora.

(2) Quando você atualizar um aplicação, a classe configurações podem ter sido alterados e podem não ser compatível com o que está guardado para fora, que pode levar a problemas.

No entanto, fizemos mais fácil para configurações de atualização de um anterior versão do aplicativo para o Mais recentes. basta ligar para ApplicationSettingsBase.Upgrade () e ele vai recuperar as configurações do versão anterior que correspondem ao versão atual da classe e armazenar -los na versão atual do arquivo user.config. Você também tem a opção de substituir este comportamento quer na sua classe de configurações ou em sua implementação do provedor.

Q: Ok, mas como faço para saber quando chamar Upgrade?

A: Boa pergunta. Em Clickonce, quando instalar uma nova versão do seu aplicação, ApplicationSettingsBase irá detectá-lo e automaticamente atualizar configurações para você no ponto configurações são carregados. Em não-Clickonce casos, não há nenhuma atualização automática - você tem que chamar Atualize-se. Aqui está uma ideia para determinar quando ao chamado Upgrade:

Tenha um ajuste boolean chamada CallUpgrade e dar-lhe um padrão valor de true. Quando seu aplicativo é iniciado -se, você pode fazer algo como:

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

Isto irá assegurar que Upgrade () é chamado apenas na primeira vez o aplicativo é executado após uma nova versão é implantado.

Eu não acredito por um segundo que ele poderia realmente trabalho -. Não há nenhuma maneira Microsoft iria fornecer essa capacidade, mas o método é não apenas o mesmo

Answer 3

O arquivo user.config é armazenado em

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

<c:\Documents and Settings> é o diretório de dados do usuário, ou não roaming (Configurações locais acima) ou em roaming.
<username> é o nome do usuário.
<companyname> é o valor CompanyNameAttribute, se disponível. Caso contrário, ignorar este elemento.
<appdomainname> é o AppDomain.CurrentDomain.FriendlyName. Isso geralmente o padrão é o nome do .exe.
<eid> é o URL, StrongName, ou Caminho, com base na evidência disponível para hash.
<hash> é um hash SHA1 de dados recolhidos pela CurrentDomain, na seguinte ordem de preferência:
1. StrongName
2. URL:
Se nenhum destes estiver disponível, utilize o caminho .exe.
<version> é configuração AssemblyVersionAttribute do AssemblyInfo.

A inscrição completa é aqui http://msdn.microsoft.com/en-us/library /ms379611.aspx

Answer 4

(eu adicioná-lo como um comentário à resposta da @ Amr, mas eu não tenho rep suficiente para fazer isso ainda.)

O no artigo do MSDN é muito claro e parece ainda se aplicam. No entanto, não menciona que o hash SHA1 é escrito de base 32 codificado, ao invés da base mais típico 16.

Eu acredito que o algoritmo sendo usado é implementado em ToBase32StringSuitableForDirName, que pode ser encontrada aqui na Microsoft fonte de referência.