Localization Assemblies for referenced DLLs

keith.vinson@imageaccess

Hi all,
I have a SA project that packs up an EXE and has 15 or so embedded DLLs. Our program has been expanded to support 11 different localizations via satellite DLLs. It appears that SA 6 automatically picks up the satellite DLLs for the packed EXE itself, but based on the resultant size of the satellite assemblies I can tell SA has not merged the satellite DLLs for the embedded DLLs. How do I get it to do so?

Thanks,
Keith

james.davies

Satellite Assemblies are not merged or embedded so that they can be loaded at run-time. They should be obfuscated (by SmartAssembly) with the same setting as the main executable.

keith.vinson@imageaccess

Hi James, thanks for the reply.

So what you are suggesting is that we create an additional project(s) for each language, in that I don't see SA allowing us to select more that one exe / dll at a time for inclusion into a project?

This being the case, then does SA not name mangle the resource names, or does SA mangle them in a way such that each embedded resource will always mangle to the same name within each localization DLL?

What of the root's (base EXE's) satellite DLLs and sub-directories that are created inside SA's output directory? In that the satellites DLLs appear to only contain the resource elements for the base EXE? How should I verify that each additional language DLL will not somehow get out of sync with the rest? Which SA project settings will effect how the resource names will be mangled? ( so I know what to check to verify that the DLLs should work)

Given that SA automatically includes any dependant DLLs into a project, would it not make sense for SA to do the same for any localization DLLs as well?

Thanks for your time,

Keith

james.davies

Sorry , I was not clear. I am not suggesting that you create a separate SA projects.
SmartAssembly will automatically obfuscate the satellite assemblies of the main assembly

keith.vinson@imageaccess

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,

Keith

james.davies

SmartAssembly is designed to deal with this situation when merging. It merges all the satellite dlls for a particular culture into one single satellite dll, in a parallel way to how the main assembly is merged.

Perhaps you are embedding instead of merging? In this case, SA has no effect at all on the satellite dll resolution system, and you need to copy across the satellite dlls of the dependencies to the output folder as if the embedded assemblies were still there.

keith.vinson@imageaccess

Ah, OK.
I understand now. I was assuming that much like how an embedded DLL is protected by being packed and encrypted (but not obfuscated) into SA's output file, so to the satellite assemblies would (should?) be protected in the same manor.

Hum, should not SA also be providing the same level of protection to the satellite DLLs as it does to the code DLLs? Maybe I misunderstand how SA works, but for me one of the key features in SA that I rely on is that string encryption is tied to the final package's hash (or whatever) such that my strings are not easily viewable or raw disk file changeable without invalidating the SA produced package, and hence rendering my program unusable.

Maybe this warrants a new feature request?

Once again, thanks for your time,

Keith

james.davies

Thanks for your suggestion. I'll add it as a feature request.