How to I18N a Setup project?

Discussion in 'Microsoft VC .NET' started by Norman Diamond, Dec 4, 2007.

  1. 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?
     
    Norman Diamond, Dec 4, 2007
    #1
    1. Advertisements

  2. > 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, Dec 9, 2007
    #2
    1. Advertisements

  3. "Johannes Passing" <> wrote in message
    news:...
    > 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.
     
    Norman Diamond, Dec 10, 2007
    #3
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Adam Clauss

    Problem creating setup project for COM project

    Adam Clauss, Sep 26, 2003, in forum: Microsoft VC .NET
    Replies:
    0
    Views:
    304
    Adam Clauss
    Sep 26, 2003
  2. Leon Gorbaty [Bentley]

    How to include an embedded (i18n) Resource.resx in MCPP Project?

    Leon Gorbaty [Bentley], Dec 9, 2003, in forum: Microsoft VC .NET
    Replies:
    2
    Views:
    394
    Doug Forster
    Dec 10, 2003
  3. msnews.microsoft.com
    Replies:
    1
    Views:
    358
    Wayne Hartell
    Jan 28, 2006
  4. unknown;
    Replies:
    2
    Views:
    290
    Bruno van Dooren [MVP VC++]
    Dec 18, 2006
  5. Sarwan
    Replies:
    1
    Views:
    291
    Ben Voigt
    Mar 9, 2007
Loading...

Share This Page