Generated installer creates shortcut that points to wrong executable

Question

I have created a Maven NetBeans Platform Application and I generate installers by running the "nbm build-installers" goal. This creates an .exe that the user can then run to automatically install my application. (In an ordinary NBPA, this would be "Package as -> Installers". Both have the same issue)

After the user runs the installer, a shortcut is placed on the user's desktop. However, for Windows 7 and Windows 8 64-bit systems, the shortcut is pointing to the wrong binary. It points to the 32-bit version. For instance, if I have an app named "SampleApp", the shortcut points to something like "C:\Program Files\sampleapp\sampleapp.exe" and NOT "C:\Program Files\sampleapp\sampleapp64.exe" as it should. Both of these binaries DO exist in this folder.

This issue is creating a real problem for us because the application calls out various DLLs that are architecture specific (32-bit version will use 32-bit dlls, 64-bit should use 64-bit dlls).

The installer needs to create a shortcut that points to the correct binary based on the user's Operating System architecture.

I have take the question from https://netbeans.org/bugzilla/show_bug.cgi?id=246710 because I have the same problem.

Anyone knows how to fix this problem? Thanks

Answer 1

It is true that there's a bug: the installer will always create a link to sampleapp.exe rather than to sampleapp64.exe. This doesn't have as much impact as one might expect. The exe file is really just a small launcher that kicks off a JVM process. If said JVM is 64 bit then that's what you are going to get regardless if the launcher .exe was actually a 32-bit binary. So most people would never see the problem in this bug. But you may be right if you are using external DLL then it may be a problem, dunno. I'll take your word for it and propose a solution.

Ok, so what really matters is the JVM you have available, not the OS itself. We can make a fairly safe assumption here: the JVM installing the application will also be the JVM which will eventually be running the application. This is at least always true if you a bundling the JRE and even in other cases it is a safe bet.

In order to fix you'll have to use your own version of ConfigurationLogic.java from the NBI stub because this is where the problem is.

In that file you'll see near the bottom

 ...
 ...
     public static final String EXECUTABLE_WINDOWS =
            BIN_SUBDIR
            + ResourceUtils.getString(ConfigurationLogic.class, "CL.app.name") + ".exe"; // NOI18N

This needs to be fixed as follows:

    private static String get64BitSuffix() {
        if (SystemUtils.isCurrentJava64Bit()) {
            return "64";
        } else {
            return "";
        }
    }


...
...
    public static final String EXECUTABLE_WINDOWS =
        BIN_SUBDIR
        + ResourceUtils.getString(ConfigurationLogic.class, "CL.app.name") + get64BitSuffix() + get64BitSuffix() + ".exe"; // NOI18N

Now to the question about how to use your own ConfigurationLogic.java in a Maven-based project: just google it.