ISSelfRegisterFiles fail if InstallDir contains non-ASCII
Hi, I'm not sure if this is a bug. I've tested on a simple project which just contains on dll which needs to be selfRegistered. Then when I tried to install this I supply the install to path to be "C:\Program Files\My Company Name\ｱｲｳÇàâ가각\". It then complains in the ISSelfRegisterFiles step: "Error 1904 Module C:\Program Files\My Company Name\???Çàâ??\DIMenu.dll" failed to register. HRESULT -2147220473. Contact your support personnel." Obviously the retrieved InstallDir is not encoded correctly in ISSelfRegisterFiles step. It was all OK when the path contains only ASCII.
The log segment is as follow: Action 15:18:48: ISSelfRegisterFiles. InstallShield 15:18:48: Initializing Property Bag... InstallShield 15:18:48: Getting file count from property bag InstallShield 15:18:48: File Count : 1 InstallShield 15:18:48: Sorting Based On Order... InstallShield 15:18:48: This setup is running on a 32-bit Windows...No need to load ISBEW64.exe InstallShield 15:18:48: Registering file C:\Program Files\My Company Name\???Çàâ??\DIMenu.dll (32-bit) InstallShield 15:18:48: Registering file C:\Program Files\My Company Name\???Çàâ??\DIMenu.dll (32-bit)
This is currently a limitation of the InstallShield custom action DLL behind ISSelfRegisterFiles - it can only handle filenames that are on the current ANSI Code Page (ACP). This limitation is shared among most of the InstallShield custom action DLLs, so the current recommendation is to use ASCII filenames - the subset that is shared across all code pages consisting of simple English characters. In some cases it's safe to use filenames from a single code page (such as the Japanese or Korean characters you show in a setup consisting only of Japanese, or only of Korean).
MichaelU wrote: This is currently a limitation of the InstallShield custom action DLL behind ISSelfRegisterFiles - it can only handle filenames that are on the current ANSI Code Page (ACP). This limitation is shared among most of the InstallShield custom action DLLs, so the current recommendation is to use ASCII filenames - the subset that is shared across all code pages consisting of simple English characters. In some cases it's safe to use filenames from a single code page (such as the Japanese or Korean characters you show in a setup consisting only of Japanese, or only of Korean).
Thanks Michael,
At any time would this be fixed? I know it exists in most SelfRegistering dlls projects. I think this causes limitations to many non-English countries users, also, leads to installation issues which are regarded as bugs in many products.:eek:
I can't offer any timeframe on when this will be fixed. For now the best practice is to limit your filenames and target directories to ASCII characters, or to characters on the target language's codepage. If your only issue with such filenames is with self-registration, it may be good to try switching to COM Extraction (component options), or to MSI self-registration (Tools > Options, and make sure to unselect and reselect self-registering for the component) to see if that lets you avoid this limitation.
