How to I18N a Setup project?

My C# code is I18N'ed by appropriately naming and editing .resx files. At
execution time, it works.

My C++ code is somewhat I18N'ed. When I put UI code in C++ I use .rc files.
When I link to a third party's DLLs I get what they supplied. When I link
to Microsoft's CRT and MFC, um... Well anyway, at execution time it seems
to be working, except when a third party's DLL has a secret dependency.

But what about the installer? A Visual Studio 2005 Setup project?

Several years ago I made an installer using Visual Studio Installer which
was a downloadable add-on for Visual Studio 6. The resulting .msi file
could handle some number of languages by default, displaying in the end
user's language if that was available in Visual Studio Installer. I didn't
have to make 9 different .msi files.

But what about a Visual Studio 2005 Setup project?

The first dependency is .Net Framework 2. If the .msi file is running on a
Japanese Windows system, it displays an EULA and demands the user's approval
to download .Net Framework 2 from Microsoft. If the .msi file is running on
a foreign language Windows system without Japanese fonts, it displays long
strings of question marks and demands the user's approval of long strings of
question marks. Though if the user approves then it downloads .Net
Framework 2 from Microsoft. It doesn't matter if I change the Visual Studio
2005 Setup project's properties from the default language (Japanese) to the
Neutral language. The resulting installation dialog does not display in the
user's language.

The second dependency is the CRT and MFC. If the .msi file is running on a
Japanese Windows system, it displays a small dialog and demands the user's
approval. Then at random it either executes a version of vcredist that was
built into the .msi, or it gets a download from Microsoft. If the .msi file
is running on a foreign language Windows system without Japanese fonts, it
displays just a few question marks and demands the user's approval. The
only problem that I noticed is the words for Runtime Library, but still,
it's essentially the same problem as the above.

Finally the .msi file installs my application. At this point, if I had not
changed the Visual Studio 2005 Setup project's properties from Japanese to
Neutral then the problem is the same as for the dependencies. However, if I
do change the project's language property from Japanese to Neutral, then
unlike the dependencies, this part of the .msi file does change. Instead of
displaying Japanese on Japanese Windows and question marks on foreign
Windows, it displays English on Japanese Windows and English on foreign
Windows. What kind of neutrality is this? If English dialogs on Japanese
Windows are neutral then shouldn't Japanese dialogs on English Windows be
neutral? Or if we're feeling really inventive, then maybe Japanese dialogs
on Japanese Windows and English dialogs on English Windows?

In all cases if the user approves installation then the result executes as
it should (except for one DLL from one supplier with a secret dependency).

Is there some way to use Visual Studio 2005 and duplicate the multilingual
installer capabilities that the old Visual Studio Installer had?

But what about the installer? A Visual Studio 2005 Setup project?
Visual Studio 2005 has pretty limited features for creating setup

projects - thus you may want to consider alternate tools such as WiX.

Several years ago I made an installer using Visual Studio Installer
which was a downloadable add-on for Visual Studio 6. The resulting
.msi file could handle some number of languages by default,
displaying in the end user's language if that was available in Visual
Studio Installer. I didn't have to make 9 different .msi files.
You want to create a single MSI with a multilinugal user interface,

right? Windows Installer does not support this out of the box, but it is
not really hard to achieve this using transforms.

The basic idea is that you create one MSI for each language you wish to
support. Then you designate one package (say, the english) as the
'master'. Using msitran, you can then create a transform for each
language like so:
msitran -g foo-en.msi foo-jp.msi jp.mst
msitran -g foo-en.msi foo-de.msi de.mst
...
Then you merge the transforms into the master MSI
msidb -d foo.msi -r jp.mst
msidb -d foo.msi -r de.mst
...

You then need some kind of custom bootstrapper that selects the
appropriate language. To use english, call msiexec without any special
parameters. To use a different language - e.g. german, pass the
parameter TRANSFORMS=:de.mst to msiexec - this directs msiexec to apply
the embedded transform named de.mst before running the package.

Regarding your problems (.Net framework download/installation) with the
standard bootstrapper, creating a custom bootstrapper may be a better
choice for you anyway. This would also give you the possibility of
customizing the download/installation procedure of the .Net framework.

The second dependency is the CRT and MFC. If the .msi file is
running on a Japanese Windows system, it displays a small dialog and
demands the user's approval. Then at random it either executes a
version of vcredist that was built into the .msi, or it gets a
download from Microsoft. If the .msi file is running on a foreign
language Windows system without Japanese fonts, it displays just a
few question marks and demands the user's approval. The only problem
that I noticed is the words for Runtime Library, but still, it's
essentially the same problem as the above.
Do you really need vcredist/the MSMs? If possible, I would prefer

deploying the libraries as private assemblies. http://tinyurl.com/3768sh
has more details on this.

Btw, microsoft.public.platformsdk.msi might be a better group for these
questions.

--Johannes

--
Johannes Passing - http://int3.de/

"Johannes Passing" <jpassing_at_hotmail_com (AT) nospam (DOT) com> wrote

Visual Studio 2005 has pretty limited features for creating setup
projects - thus you may want to consider alternate tools such as WiX.

You want to create a single MSI with a multilinugal user interface, right?
Windows Installer does not support this out of the box, but it is not
really hard to achieve this using transforms.

Windows Installer does (or rather, Windows Installer usually displays
dialogs in the language version of Windows where the application is being
installed), but as you pointed out, Visual Studio 2005 doesn't support many
Windows Installers that way. So I either have to learn WiX or transforms.
I'll try to follow your advice for transforms and custom bootstrapper.

The basic idea is that you create one MSI for each language you wish to
support. Then you designate one package (say, the english) as the
'master'.

Japanese will be the master. For the C# components I've added an English
satellite assembly that works, and this product's C++ components don't have
any user interaction (though I've done resource-only rc files before). For
the installer I will try to follow your advice for transforms and custom
bootstrapper.

Regarding your problems (.Net framework download/installation) with the
standard bootstrapper, creating a custom bootstrapper may be a better
choice for you anyway. This would also give you the possibility of
customizing the download/installation procedure of the .Net framework.

If the target system doesn't have .Net Framework 2 then it will have to be
installed. The problem was that the dialogs to install .Net Framework 2
(and CRT) sometimes weren't displayed in a language that could be displayed
on the target system.

Do you really need vcredist/the MSMs? If possible, I would prefer
deploying the libraries as private assemblies.

Actually I already made private assemblies and they were working on XP and
Vista (failing on 2000 and not tested on 2003). But Microsoft pushes MSMs
so I tried to do it. MSMs really do have at least two advantages: The DLLs
are shareable so users don't have to install additional copies for every
application, and later releases of security fixes will take effect in the
shared versions.

Btw, microsoft.public.platformsdk.msi might be a better group for these
questions.

Thank you. If the problem involved something other than I18N I probably
would have looked for that group.