Creazione del package e distribuzione delle risorse
Aggiornamento: novembre 2007
.NET Framework utilizza un modello hub e spoke per creare il package delle risorse e distribuirle. L'hub è l'assembly principale che contiene il codice eseguibile non localizzabile e le risorse relative a singole impostazioni cultura, denominate neutre o predefinite. Le impostazioni cultura predefinite sono le impostazioni cultura di fallback dell'applicazione. Ciascuno spoke si collega a un assembly satellite che contiene le risorse relative a singole impostazioni cultura, ma non contiene codice.
Questo modello presenta diversi vantaggi:
Una volta distribuita un'applicazione, sarà possibile aggiungere risorse per nuove impostazioni cultura in modo incrementale. Poiché lo sviluppo successivo di risorse specifiche delle impostazioni cultura può richiedere molto tempo, questa soluzione consente di rilasciare l'applicazione principale e distribuire successivamente le risorse specifiche delle impostazioni cultura.
È possibile aggiornare e modificare gli assembly satellite di un'applicazione senza ricompilare l'applicazione.
L'applicazione può limitarsi a caricare solo gli assembly che contengono le risorse necessarie per particolari impostazioni cultura. In tal modo è possibile ridurre notevolmente l'utilizzo delle risorse di sistema.
Questo modello presenta tuttavia anche alcuni svantaggi:
È necessario gestire più insiemi di risorse.
Il costo iniziale del test di un'applicazione aumenta, perché è necessario verificare diverse configurazioni. Si osservi però che a lungo termine sarà più semplice e meno costoso eseguire il test di un'applicazione centrale con vari satelliti, piuttosto che verificare e gestire diverse versioni internazionali parallele.
Convenzioni di denominazione delle risorse
Quando si crea il package delle risorse dell'applicazione, è necessario denominarle utilizzando le convenzioni di denominazione delle risorse richieste da Common Language Runtime. Il runtime identifica una risorsa in base al nome o alla firma delle impostazioni cultura. Alle diverse impostazioni cultura è assegnato un nome univoco costituito da una sigla di due caratteri minuscoli che identifica una lingua e, se necessario, da una sigla di due caratteri maiuscoli che identifica impostazioni cultura secondarie associate a un paese o un'area geografica specifica. La seconda sigla è separata dalla prima tramite un trattino (-). Sono esempi validi ja-JP per il giapponese del Giappone, en-US per l'inglese degli Stati Uniti, de-DE per il tedesco della Germania e de-AT per il tedesco dell'Austria. Per un elenco completo dei nomi delle impostazioni cultura, vedere la classe CultureInfo.
Processo di fallback delle risorse
Nel modello hub e spoke per la creazione del package e la distribuzione delle risorse viene utilizzato un processo di fallback per l'individuazione delle risorse appropriate. Quando viene richiesto un oggetto ResourceSet non disponibile, Common Language Runtime cerca nella gerarchia delle impostazioni cultura una risorsa di fallback appropriata che corrisponda il più possibile alla richiesta dell'utente e, solo in ultima analisi, genera un'eccezione. A ciascun livello della gerarchia, se viene individuata una risorsa appropriata, questa viene utilizzata dal runtime. In caso contrario, la ricerca continua al livello successivo. Il processo di fallback delle risorse viene descritto nei passaggi riportati di seguito.
Il runtime esegue la ricerca nella Global Assembly Cache di un assembly che corrisponde alle impostazioni cultura richieste dall'applicazione.
La Global Assembly Cache può memorizzare assembly di risorse condivisi da più applicazioni. In tal modo non è necessario includere set di risorse specifici nella struttura di directory di ogni applicazione creata. Se il runtime trova un riferimento all'assembly, cerca nell'assembly la risorsa richiesta. Se trova la voce nell'assembly, utilizza la risorsa. Se non trova la voce, continua la ricerca.
Il runtime cerca quindi nella directory dell'assembly in esecuzione una directory che corrisponda alle impostazioni cultura richieste. Se la trova, vi cerca un assembly satellite valido per le impostazioni cultura richieste. Il runtime cerca quindi nell'assembly satellite la risorsa richiesta. Se trova la risorsa, la utilizza. Se non trova la risorsa, continua la ricerca.
Il runtime esegue una nuova ricerca nella Global Assembly Cache, questa volta al fine di individuare l'assembly padre della risorsa richiesta. Se la Global Assembly Cache contiene l'assembly padre, il runtime vi cerca la risorsa richiesta.
Le impostazioni cultura padre vengono considerate le impostazioni cultura di fallback appropriate. Avvalersi del padre è la soluzione più indicata. È preferibile fornire una risorsa qualsiasi piuttosto che generare un'eccezione. Questo processo consente anche di riutilizzare le risorse. È necessario includere una risorsa particolare a livello del padre solo se le impostazioni cultura del figlio non richiedono la localizzazione della risorsa desiderata. Se, ad esempio, vengono forniti assembly satellite per en (inglese neutro), en-GB (l'inglese del Regno Unito) e en-US (l'inglese degli Stati Uniti), il satellite en conterrà la terminologia comune e i satelliti en-GB e en-US potranno fornire gli override per i soli termini che differiscono.
Il runtime cerca quindi una directory padre nella directory dell'assembly in esecuzione. Se esiste una directory padre, il runtime vi cerca un assembly satellite valido per le impostazioni cultura padre. Se trova l'assembly, il runtime vi cerca la risorsa richiesta. Se trova la risorsa, la utilizza. Se non trova la risorsa, continua la ricerca.
Il runtime cerca quindi gli assembly padre, come nel passaggio precedente, in numerosi livelli. Le diverse impostazioni cultura prevedono un solo padre, ma ogni padre può avere a sua volta un padre.
Se la risorsa non viene trovata nelle impostazioni cultura originariamente specificate né in alcuno degli elementi padre, verrà utilizzata la risorsa delle impostazioni cultura di fallback predefinite. A partire dalla versione 2.0 di .NET Framework, è possibile specificare come percorso di fallback finale delle risorse un assembly satellite anziché un assembly principale. Per verificare se il percorso di fallback finale delle risorse è nell'assembly principale o in un assembly satellite, è possibile utilizzare l'oggetto NeutralResourcesLanguageAttribute con l'enumerazione UltimateResourceFallbackLocation.
.gif "Nota")
Nota:La risorsa predefinita è l'unica risorsa compilata con l'assembly principale. Tale risorsa costituisce il fallback finale, ovvero l'elemento padre finale, a meno che non venga specificato un assembly satellite mediante NeutralResourcesLanguageAttribute. Pertanto, si raccomanda di includere sempre un set predefinito di risorse nell'assembly principale. In tal modo si può essere certi che non verranno generate eccezioni. L'inclusione di un file di risorse predefinito assicura la disponibilità di un fallback per tutte le risorse e garantisce che per l'utente sia presente almeno una risorsa, anche se non è specifica della lingua.
Infine, se il runtime non trova una risorsa per impostazioni cultura di fallback predefinite, verrà generata un'eccezione in cui viene indicato che la risorsa non è stata trovata.
A titolo esemplificativo, si consideri il caso di un utente che richiede una risorsa localizzata in spagnolo del Messico. In conformità alle convenzioni di denominazione delle risorse sopra descritte, il runtime cerca nella Global Assembly Cache l'assembly che corrisponde alle impostazioni cultura richieste, "es-MX". Se non lo trova, il runtime cerca una directory "es-MX" nella directory dell'assembly in esecuzione. Se non la trova, il runtime cerca nuovamente nella Global Assembly Cache un assembly padre che corrisponda alle impostazioni cultura di fallback appropriate, in questo caso "es" (spagnolo). Se l'assembly padre non viene trovato, il runtime risale l'intera gerarchia alla ricerca dell'assembly per le impostazioni cultura "es-MX", finché non trova una risorsa corrispondente. Se non trova alcuna risorsa, il runtime utilizza la risorsa delle impostazioni cultura predefinite.
Fallback finale in un assembly satellite
A partire dalla versione 2.0 di .NET Framework, è possibile rimuovere le risorse dall'assembly principale e specificare che le risorse di fallback finali si trovano in un assembly satellite corrispondente a impostazioni cultura specifiche. Allo scopo di controllare il processo di fallback, utilizzare l'oggetto NeutralResourcesLanguageAttribute. Per specificare il percorso da cui ResourceManager deve estrarre le risorse di fallback, ovvero l'assembly principale o quello satellite, è stato aggiunto un nuovo costruttore alla classe NeutralResourcesLanguageAttribute che accetta un parametro aggiuntivo UltimateResourceFallbackLocation.
Nell'esempio riportato di seguito viene illustrato come applicare l'attributo a livello di classe.
[assembly: NeutralResourcesLanguageAttribute("de" , UltimateResourceFallbackLocation.Satellite)]
Per il percorso di fallback finale, viene richiesto a ResourceManager di cercare le risorse nella sottodirectory "de" della directory dell'assembly attualmente in esecuzione.
Alternativa suggerita per la creazione del package
A causa di limiti di tempo o di budget, può non essere fattibile creare un set di risorse per tutte le impostazioni cultura secondarie supportate dall'applicazione. In tal caso, è possibile creare un assembly satellite singolo per impostazioni cultura padre che verrà utilizzato anche per tutte le impostazioni cultura secondarie correlate. È possibile fornire, ad esempio, un singolo assembly satellite inglese (en), che verrà recuperato dagli tutti gli utenti che richiedono risorse in inglese e un singolo assembly satellite tedesco (de) per tutti gli utenti che richiedono risorse in tedesco. In quest'ultimo caso, le richieste di risorse in tedesco della Germania (de-DE), tedesco dell'Austria (de-AT) e tedesco della Svizzera (de-CH) verrebbero tutte ricondotte all'unico assembly satellite tedesco (de). Selezionare con attenzione le risorse da compilare con l'assembly principale. Le risorse predefinite rappresentano il fallback finale e, pertanto, è possibile che siano le risorse che verranno richieste dalla maggioranza degli utenti dell'applicazione. Sebbene questa soluzione preveda la distribuzione di risorse meno specifiche in termini di lingua, essa consente di ridurre notevolmente i costi di localizzazione dell'applicazione.