>
> Greco Giuseppe wrote:
>
> >what's about something like that? Giving the following resource files
> >
> > Global.resx
> > Another.resx
> > ... .resx
> >
> >
> >we could have a separate resource manager for each resource file,
> >
> >
> This means storing *all* the resources in a single assembly
>
> I don't quite understand how your implementation is supposed to work.
> The static constructor will only be called once so:
>
> static ResourceUtils() {
> Assembly assembly = Assembly.GetCallingAssembly();
> Global = new
> ResourceManager(assembly.GetName().Name + GlobalResx, assembly);
> Another = new
> ResourceManager(assembly.GetName().Name + AnotherResx, assembly);
> ...
>
> }
>
> will only allow the loading of resources whatever the calling
> assembly is at type initialization time ( probably
> NAnt.Core.dll ? ). This means that we would have to store
> *all* resources for *all* asemblies in NAnt.Core. I thought
> we agreed that it would be better to have each assembly store
> its own localised resources ?
>
No, that was just a way to have more than one *.resx file per
assembly.
>
> >solving also the problem with VS.NET:
> >
> >
> >
> it has no bearing on the vs.net problem. That issue only
> related to the
> naming of the embedded resource structure - so Another.resx
> still maps
> to <defaultnamespace>.Another.resource in the final assembly ( when
> built by vs.net ).
>
Exactly, meaning that in the example above we would have something
like
MyNamespace.Global.resource
MyNamespace.Another.resoruce
...
>
>
> I think that a variation on your register assemblies proposal
> could work
> well and be more flexible going forward:
>
> public sealed class ResourceUtils {
> private static ResourceManager _sharedResourceManager;
> private static Hashtable _resourceManagerDictionary = new
> Hashtable();
>
> ...
> ...
> private static void RegisterAssembly(Assembly assembly) {
> lock (_resourceManagerDictionary) {
>
> _resourceManagerDictionary.Add(assembly.GetName().Name,
> new
> ResourceManager(assembly.GetName().Name, assembly));
> }
> }
> private static void RegisterSharedAssembly(Assembly assembly) {
> lock (_sharedResourceManager) {
> _sharedResourceManager = new
> ResourceManager(assembly.GetName().Name, assembly);
> }
> }
>
I think the RegisterSharedAssembly() method is not necessary; we could
just always use the RegisterAssembly() method (adding also the shared
resource manager to the hashtable).
In any case the problem related to the naming of the embedded resource
structure
still remains... In the code above you assume this name always
corresponds to
the assembly name... but it does not (e.g.
MyNamespace.Another.resources).
> public static string GetString(string name, CultureInfo culture) {
> string localizedString = null;
> ResourceManager resourceManager = null;
> Assembly assembly = Assembly.GetCallingAssembly();
>
> if ( !
> _resourceManagerDictionary.Contains(assembly.GetName().Name ) ) {
> lock (_resourceManagerDictionary) {
> RegisterAssembly(assembly);
> }
> }
> // get the required Manager
> resourceManager =
> _resourceManagerDictionary[assembly.GetName().Name] as
> ResourceManager;
> localizedString = resourceManager.GetString(name,
> culture);
>
> // try the shared resources if we didn't find it in the
> specific resource manager
> if ( localizedString == null && _sharedResourceManager !=
> null) {
> return _sharedResourceManager.GetString(name,
> culture);
> }
>
> return localizedString;
> }
>
> }
>
> Since there are only 2 cases.
> - load resource from the current assembly
> - load the resource from the shared resource assembly
>
> and somewhere in NAnt startup sequence we'd call:
>
> ResourceUtils:RegisterSharedAssembly( Assembly.LoadFrom(
> "NAnt.SharedResources.dll" ) );
ResourceUtils.RegisterAssembly(Assembly.LoadFrom("NAnt.SharedResources.d
ll"));
would be enought... isn't it?
j3d.
>
>
> Ian
>
---------------------------------- DISCLAIMER ----------------------------------
This message (including any attachments) is confidential and may be
privileged. If you have received it by mistake please notify the sender
by return e-mail and delete this message from your system.Any unauthorised
use or dissemination of this message in whole or in part is strictly
prohibited. Please note that e-mails are susceptible to change.
Banca del Gottardo (including its group companies) shall not be liable for
the improper or incomplete transmission of the information contained in this
communication nor for any delay in its receipt or damage to your system.
Under no circumstances this message can be considered as a written acceptance
or confirmation of an instruction/order given to Banca del Gottardo.
Instructions and orders cannot be accepted or confirmed via e-mail.
Banca del Gottardo (or its group companies) does not guarantee that the
integrity
of this communication has been maintained nor that this communication is free of
viruses, interceptions or interference.
---------------------------------------------------------------------------------
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
nant-developers mailing list
nant-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-developers
