Hi James, thanks for the response.
That leaves me with one final question. Let's see if I can frame it correctly.
Our application consists of one root EXE and 15 supporting DLLs, therefore our SA project contains the root EXE, and 15 supporting DLLs (library assemblies) which were automatically found and included by SA. So far so good.
We then localize or application into 11 languages. When we re-run the project through SA, SA picks up the root EXE, the 15 supporting DLLs, and the 11 satellite assemblies (localized resources) for the root EXE, but SA fails to pickup the 11 satellite assemblies for each of the 15 support DLLs.
Which by my understanding will leave our application only half baked. In that only the main EXE's resource strings will render in any of the supported languages. But any string resource referenced by any of the 15 support DLLs will fail to resolve because the needed satellite assemblies were not included by SA in SA's packed and encrypted output file.
Given that SA will name mangle the resource names of all resource strings referenced by the EXE or support DLLs, but any satellite assemblies not ingested by SA will not be so named mangled and will therefore fail to lineup with the mangled names, and hence will not work. So, even if I include the satellite assemblies in our installation package the DotNet resource manager will still not be able to resolve the affected resource strings, thus rendering our application broken.
So my question becomes how do I get SA to include all of the localization DLLs needed by the support DLLs? For example in my case SA should include (1 + 15) * 11 = 176 code files in its output package (EXE) but by my guess it only includes 1 * 11 + 15= 27 code files.
Thanks again for your time,