Re: [nant-dev] ResourceUtil rewind

[Ian MacLean]

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.
 

aah ok - I'm not sure that its necessary though - one Strings.resx for 
localized strings per assembly is probably sufficent.
Besides, creating the two resourcemanagers in the static constructor 
doesn't solve the problem as its only called a single time. You would 
need to store a more complicated structure with 'x' ResourceManagers per 
assembly - ie 1 for each embedded resource file.

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).
 

sure - thats fine. Except-  how would you know to use that one as the 
fallback if the resource isn't found in the current assembly's 
ResourceManager ? We don't want to try all of them. Hardcode the name 
"NAnt.SharedResources" in the GetString() method ?

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).
 

sure but if we assume strings.resx and namespace == assemblyname then we 
always get:

MyNamespace.Strings.resources
doh ! -- except the namespace doesn't equal the assembly name - for example 
NAnt.DotNet => NAnt.DotNetTasks.dll. Ok - another way around this is to just 
change the vs.net project files to have *no* default namespace and set the prefix 
manually on each resx file. I don't think we should be working to hard to 
workaround vs.net't busted build system especially since the official build is the 
'built by nant' one.

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?
 

yep - if we can identify the shared resourcemaneger to use as a fallback.
Ian
-------------------------------------------------------
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_id=6595&alloc_id=14396&op=click
_______________________________________________
nant-developers mailing list
nant-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-developers