Empacotando e implantando recursos em aplicativos de área de trabalho

 

Aplicativos se baseiam no .NET Framework Gerenciador de recursos, representado pelo ResourceManager classe para recuperar recursos localizados. O Gerenciador de recursos pressupõe que um modelo de hub e spoke é usado para empacotar e implantar recursos. O hub é o principal assembly que contém o código executável nonlocalizable e os recursos para uma única cultura, chamado de neutro ou cultura padrão. A cultura padrão é a cultura de fallback para o aplicativo; é a cultura cujos recursos serão usados se recursos localizados não podem ser encontrados. Cada spoke conecta-se a um assembly satélite que contém os recursos para uma única cultura, mas não contém qualquer código.

Há várias vantagens para este modelo:

  • Incrementalmente, você pode adicionar recursos de culturas novas depois de ter implantado um aplicativo. Porque o desenvolvimento subsequente de recursos específicos à cultura pode exigir uma quantidade significativa de tempo, isso permite que você libere seu aplicativo principal primeiro e fornecer recursos específicos de cultura em uma data posterior.

  • Você pode atualizar e alterar assemblies de satélite do aplicativo sem recompilar o aplicativo.

  • Um aplicativo precisa carregar apenas os assemblies de satélite que contêm os recursos necessários para uma determinada cultura. Isso pode reduzir significativamente o uso de recursos do sistema.

No entanto, também há desvantagens para este modelo:

  • Você deve gerenciar vários conjuntos de recursos.

  • Aumenta o custo inicial de um aplicativo de teste, porque você deve testar várias configurações. Observe que a longo prazo será mais fácil e menos dispendioso para testar um aplicativo básico com vários satélites que testar e manter várias versões internacionais paralelas.

Ao empacotar os recursos de seu aplicativo, você deve nomeá-los usando as convenções de nomenclatura de recursos que espera que o common language runtime. O tempo de execução identifica um recurso por seu nome de cultura. Cada cultura tem um nome exclusivo, que normalmente é uma combinação de um nome de cultura de duas letras, letras minúsculas associado a um idioma e, se necessário, um nome de subcultura de duas letras, maiusculas associados com um país ou região. O nome de subcultura segue o nome da cultura, separado por um traço (-). Exemplos incluem ja-JP para japonês falado no Japão, en-US para inglês como falado nos Estados Unidos, de-DE para alemão como falado na Alemanha, ou de-AT para alemão como falado na Áustria. Consulte o suporte ao idioma nacional (NLS) API referência no Go Global Developer Center para obter uma lista completa de nomes de cultura.

System_CAPS_noteObservação

Para obter informações sobre como criar arquivos de recursos, consulte Criar arquivos de recursos para aplicativos de área de trabalho e Criando assemblies satélite para aplicativos de área de trabalho na biblioteca MSDN.

O modelo hub e spoke para empacotamento e implantação de recursos usa um processo de fallback para localizar recursos apropriados. Se um aplicativo solicita um recurso localizado que não está disponível, o common language runtime procura a hierarquia das culturas para um recurso de fallback apropriado que melhor corresponde a solicitação do aplicativo do usuário e gera uma exceção apenas como último recurso. Em cada nível da hierarquia, se um recurso apropriado for encontrado, o runtime usará. Se o recurso não for encontrado, a pesquisa continuará no próximo nível.

Para melhorar o desempenho da pesquisa, aplicar o NeutralResourcesLanguageAttribute de atributos para seu assembly principal e passe o nome da linguagem neutra que funcione com o assembly principal.

System_CAPS_tipDica

Você poderá usar o < relativeBindForResources > elemento de configuração para otimizar o processo de fallback de recurso e o processo pelo qual o tempo de execução de testes para módulos de recursos. Para obter mais informações, consulte a seção Otimizando o Processo de Fallback do Recurso.

O recurso de processo de fallback é envolve as seguintes etapas:

  1. O runtime primeiro verifica o cache de assembly global para um assembly que coincide com a cultura solicitada para seu aplicativo.

    O cache de assembly global pode armazenar módulos de recursos que são compartilhados por vários aplicativos. Isso permite que você precise incluir conjuntos de recursos específicos na estrutura de diretórios de cada aplicativo que você criar. Se o tempo de execução encontra uma referência ao assembly, ele pesquisa o assembly para o recurso solicitado. Se ele encontrar a entrada no assembly, ele usa o recurso solicitado. Se não encontrar a entrada, ele continua a pesquisa.

  2. Em seguida, o runtime verifica o diretório do assembly em execução no momento para um diretório que corresponda a cultura solicitada. Se ele encontrar o diretório, ele procurará nesse diretório um assembly satélite válido para a cultura solicitada. O tempo de execução, em seguida, procura o assembly satélite para o recurso solicitado. Se ele encontrar o recurso no assembly, ele usa. Se não encontrar o recurso, ele continua a pesquisa.

  3. Em seguida, o tempo de execução consulta o Windows Installer para determinar se o assembly satélite para instalação sob demanda. Se assim, ele lida com a instalação, carrega o assembly e as pesquisas ele ou o recurso solicitado. Se ele encontrar o recurso no assembly, ele usa. Se não encontrar o recurso, ele continua a pesquisa.

  4. O tempo de execução gera o AppDomain.AssemblyResolve evento para indicar que não é possível localizar o assembly satélite. Se você optar por manipular o evento, o manipulador de eventos pode retornar uma referência ao assembly satélite cujos recursos serão usados para a pesquisa. Caso contrário, retornará o manipulador de eventos null e continua a pesquisa.

  5. O próximo tempo de execução pesquisa global assembly cache novamente, desta vez para o assembly pai da cultura solicitada. Se o assembly pai existe no cache de assembly global, o runtime procura o assembly para o recurso solicitado.

    A cultura pai é definida como a cultura de fallback apropriada. Considere pais como candidatos de fallback, pois fornecer que qualquer recurso é preferível para lançar uma exceção. Esse processo também permite a reutilização de recursos. Você deve incluir um determinado recurso no nível pai somente se a cultura filho não precisa localizar o recurso solicitado. Por exemplo, se você fornecer assemblies de satélite para en (neutro em inglês), en-GB (inglês falado no Reino Unido) e en-US (inglês falado nos Estados Unidos), o satélite en conteria a terminologia comum e os satélites en-GB e en-US poderia fornecer substituições para apenas esses termos diferentes.

  6. Em seguida, o runtime verifica o diretório do assembly em execução no momento para ver se ele contém um diretório pai. Se houver um diretório pai, o tempo de execução procura no diretório de um assembly satélite válido para a cultura pai. Se ele encontrar o assembly, o runtime procura o assembly para o recurso solicitado. Se ele encontrar o recurso, ele usa. Se não encontrar o recurso, ele continua a pesquisa.

  7. O tempo de execução próxima consulta o Windows Installer para determinar se o assembly satélite pai deve ser instalado por demanda. Se assim, ele lida com a instalação, carrega o assembly e as pesquisas ele ou o recurso solicitado. Se ele encontrar o recurso no assembly, ele usa. Se não encontrar o recurso, ele continua a pesquisa.

  8. O tempo de execução gera o AppDomain.AssemblyResolve evento para indicar que não é possível localizar um recurso de fallback apropriado. Se você optar por manipular o evento, o manipulador de eventos pode retornar uma referência ao assembly satélite cujos recursos serão usados para a pesquisa. Caso contrário, retornará o manipulador de eventos null e continua a pesquisa.

  9. As pesquisas próximas tempo de execução pai assemblies, como as três etapas anteriores, por meio de vários níveis possíveis. Cada cultura tem apenas um pai, que é definido como o CultureInfo.Parent propriedade, mas um pai pode ter seu próprio pai. Pesquisar pai culturas para quando uma cultura Parent propriedade retorna CultureInfo.InvariantCulture; para o fallback de recurso, a cultura invariável não é considerada uma cultura pai ou uma cultura que pode ter recursos.

  10. Se a cultura originalmente especificado e todos os pais tenham sido pesquisados e o recurso ainda não for encontrado, o recurso para a cultura (fallback) padrão será usado. Normalmente, os recursos para a cultura padrão são incluídos no assembly principal do aplicativo. No entanto, você pode especificar um valor de Satellite para o Location propriedade o NeutralResourcesLanguageAttribute atributo para indicar que o local de fallback final de recursos é um assembly satélite, em vez do assembly principal.

    System_CAPS_noteObservação

    O recurso de padrão é o único recurso que pode ser compilado com o assembly principal. A menos que você especifique um assembly satélite usando o NeutralResourcesLanguageAttribute atributo, é o fallback final (final pai). Portanto, é recomendável que você sempre incluir um conjunto padrão de recursos no assembly principal. Isso ajuda a evitar exceções sejam lançados. Com a inclusão de um padrão fornecem um fallback para todos os recursos e certifique-se de que pelo menos um recurso de arquivo de recurso está sempre presente para o usuário, mesmo se não houver culturalmente específico.

  11. Por fim, se o tempo de execução não encontrar um recurso para uma cultura (fallback) padrão, um MissingManifestResourceException ou MissingSatelliteAssemblyException exceção é gerada para indicar que o recurso não pôde ser encontrado.

Por exemplo, suponha que as solicitações do aplicativo um recurso localizado para Espanhol (México) (a cultura es-MX). O runtime primeiro procura o cache de assembly global para o assembly correspondente es-MX, mas não encontrá-lo. O tempo de execução, em seguida, procura no diretório do assembly em execução no momento para um diretório de es-MX. Caso de falha, o tempo de execução procura o cache de assembly global novamente um assembly pai que reflete a cultura de fallback apropriada — neste caso, es (espanhol). Se o assembly pai não for encontrado, o runtime procura todos os níveis possíveis de assemblies do pai para a cultura es-MX até encontrar um recurso correspondente. Se um recurso não for encontrado, o tempo de execução usa o recurso para a cultura padrão.

Sob as seguintes condições, você pode otimizar o processo pelo qual o tempo de execução procura recursos em assemblies satélites

  • Assemblies de satélite são implantados no mesmo local que o assembly de código. Se o assembly de código está instalado no Cache de assemblies global, assemblies satélites também são instalados no cache de assembly global. Se o assembly de código é instalado em um diretório, assemblies satélite são instalados em pastas específicas de cultura do diretório.

  • Assemblies de satélite não são instalados sob demanda.

  • O código do aplicativo não processa o AppDomain.AssemblyResolve evento.

Otimiza a investigação de assemblies de satélite, incluindo o < relativeBindForResources > elemento e a configuração de seu enabled atributo true no arquivo de configuração do aplicativo, conforme mostrado no exemplo a seguir.


<configuration>
   <runtime>
      <relativeBindForResources enabled="true" />
   </runtime>
</configuration>

A investigação otimizada para assemblies satélite é um recurso opt-in. Ou seja, o tempo de execução segue as etapas documentadas no O Processo de Fallback do Recurso a menos que o < relativeBindForResources > elemento está presente no arquivo de configuração do aplicativo e sua enabled atributo é definido como true. Se esse for o caso, o processo de investigação de um assembly satélite é modificado como segue:

  • O tempo de execução usa o local do assembly de código pai para investigar o assembly satélite. Se o assembly pai estiver instalado no cache de assembly global, o tempo de execução de testes no cache, mas não no diretório do aplicativo. Se o assembly pai estiver instalado em um diretório de aplicativo, o tempo de execução de testes no diretório do aplicativo, mas não no cache de assembly global.

  • O tempo de execução não consulta o Windows Installer para instalação sob demanda dos assemblies satélites.

  • Se a investigação de um assembly de recurso específico falhar, o tempo de execução não gera o AppDomain.AssemblyResolve evento.

Opcionalmente, você pode remover recursos do assembly principal e especificar que o tempo de execução deve carregar os recursos de fallback finais de um assembly satélite correspondente a uma cultura específica. Para controlar o processo de fallback, você deve usar o NeutralResourcesLanguageAttribute.NeutralResourcesLanguageAttribute(String, UltimateResourceFallbackLocation) construtor e fornecer um valor para o UltimateResourceFallbackLocation parâmetro que especifica se o Gerenciador de recursos deve extrair os recursos de fallback do assembly principal ou de um assembly satélite.

O exemplo a seguir usa o NeutralResourcesLanguageAttribute atributo para armazenar recursos de fallback do aplicativo em um assembly satélite para o idioma francês (fr). O exemplo tem dois arquivos de recurso com base em texto que definem um recurso de cadeia de caracteres único chamado Greeting. O primeiro, resources.fr.txt, contém um recurso de idioma francês.

Greeting=Bon jour!

O segundo, resources,ru.txt, contém um recurso de idioma russo.

Greeting=Добрый день

Esses dois arquivos são compilados em arquivos. Resources executando o gerador de arquivo (Resgen.exe) da linha de comando. Para o recurso de idioma francês, o comando é:

Resgen.exe resources.fr.txt

Para o recurso de idioma russo, o comando é:

Resgen.exe resources.ru.txt

Os arquivos. resources são incorporados em bibliotecas de vínculo dinâmico executando Vinculador de assembly (Al.exe) do comando de linha para o recurso de idioma francês da seguinte maneira:

Al /t:lib /embed:resources.fr.resources /culture:fr /out:fr\Example1.resources.dll

e para o recurso de idioma russo da seguinte maneira:

Al /t:lib /embed:resources.ru.resources /culture:ru /out:ru\Example1.resources.dll

O código do aplicativo reside em um arquivo chamado Example1.cs ou Example1.vb. Ele inclui o NeutralResourcesLanguageAttribute atributo para indicar que o recurso de aplicativo padrão é no subdiretório fr. Ele cria uma instância do Gerenciador de recursos, recupera o valor da Greeting recursos e o exibe para o console.

using System;
using System.Reflection;
using System.Resources;

[assembly:NeutralResourcesLanguage("fr", UltimateResourceFallbackLocation.Satellite)]

public class Example
{
   public static void Main()
   {
      ResourceManager rm = new ResourceManager("resources", 
                                               typeof(Example).Assembly);
      string greeting = rm.GetString("Greeting");
      Console.WriteLine(greeting); 
   }
}

Em seguida, você pode compilar código-fonte c# na linha de comando da seguinte maneira:

CSC Example1.cs

O comando para o compilador do Visual Basic é muito semelhante:

Vbc Example1.vb

Porque não há recursos incorporados no assembly principal, você não precisa compilar, usando o /resource switch.

Quando você executar o exemplo de um sistema cujo idioma for algo diferente de russo, ele exibe a seguinte saída:

Bon jour!

Restrições de tempo ou orçamento podem impedir a criação de um conjunto de recursos para cada subcultura dá suporte a seu aplicativo. Em vez disso, você pode criar um assembly satélite único para uma cultura pai que todos os relacionados subcultures pode usar. Por exemplo, você pode fornecer um assembly de único satélite em inglês (en) que é recuperado por usuários que solicitam recursos em inglês específica de região e um assembly único satélite alemão (de) para os usuários que solicitam recursos alemães específica da região. Por exemplo, solicitações de para alemão como falado na Alemanha (de-DE), Áustria (de-AT) e da Suíça (de-CH) faria fallback para o assembly satélite alemão (de). Os recursos padrão são o fallback final e, portanto, devem ser os recursos que serão solicitados pela maioria dos usuários do seu aplicativo, então escolha cuidadosamente esses recursos. Essa abordagem implanta recursos que são menos culturalmente específicos, mas podem reduzir significativamente os custos de localização do seu aplicativo.

Mostrar: