Comments
Sort by recent activity
My issue cleared after I reboot the machine we use to run SA on our builds. without changing anything SA began to work correctly / comments
My issue cleared after I reboot the machine we use to run SA on our builds. without changing anything SA began to work correctly
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 / comments
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 wou...
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 / comments
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 p...
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 / comments
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 ti...