Localisation by updating exe only (not the resources.dlls)

  • Thread starter Thread starter Daniel Moth
  • Start date Start date
D

Daniel Moth

Hi

So far I have found no info on MSDN, ngs or the rest of the web... Trying
with SP2 on CE 4.2-based device...

I have an exe with a bunch of resources.dlls... The localisation mechanism
works fine as long as the satellite assemblies and the main one have the
same version number. If, however, I update only the EXE, then localisation
fails (i.e. even though the locale is not English, English strings are
displayed - so the fallback mechanism has kicked into place). This seems
different to a brief experiment I run on the desktop.

Is this the same for your localised CF application (i.e. whenever you update
the exe you must update every resources.dll as well)? If not please just let
me know so I can dig into it further... Any pointers are much appreciated...

Cheers
Daniel
 
OK I have been digging deeper into this and have come up with the following
stream of thoughts (and partial solution) which I share with you.

1. My experiments show that it is indeed a limitation that to update a
localised app it is not enought to ship the exe but all resources.dll files
must be updated as well (in other words: The version of the main assembly
must exactly match the version of the satellite asemblies except for the
revision of course)

* I'd love for someone to prove me worng on the first point so go ahead
please. Presuming statement 1 is correct though... *

2. SatelliteContractVersionAttribute seems to be the answer to the problem
stated. For its use and effects read the documentation. However it also
seems to be broken on the CF.
a) Either someone else has made it work for them [PLEASE let me know]
b) ..or it is written somewhere that it doesn't work on CF [PLEASE point
me to that writing]

* Presuming statement 2 is correct... *

3. Looking at what goes on in the ResourceManager it is no surpise. The
protected static method that is responsible for identifying the version to
load is called GetSatelliteContractVersion. This method simply returns the
version of the main assembly(!). On the desktop framework the method first
iterates the Assembly's attributes to see if there is a
SatelliteContractVersionAttribute so it can override the version with
that...

4. So by inheriting from ResourceManager (combined with using reflection to
invoke private methods & copying pasting from Anakrino) I created a class
that proves theory from step 3. [if you are interested I can email that].

5. The problem however is that I had to hardcode the version number returned
by GetSatelliteContractVersion (rather than use the
SatelliteCotnractVersion) because Assembly.GetCustomAttributes is not
supported on CF.

Cheers
Daniel
 
Back
Top