Maven 生成的安装程序创建指向错误可执行文件的快捷方式

我创建了一个Maven NetBeans平台应用程序，并通过运行“nbm构建安装程序”目标生成安装程序。这将创建一个.exe，然后用户可以运行它来自动安装我的应用程序。（在普通的NBPA中，这将是“打包为->安装程序”。两者都有相同的问题）

用户运行安装程序后，将在用户桌面上放置快捷方式。但是，对于Windows 7和Windows 8 64位系统，快捷方式指向错误的二进制文件。它指向32位版本。例如，如果我有一个名为“SampleApp”的应用程序，则快捷方式指向类似“C:\Program Files\SampleApp\SampleApp.exe”的内容，而不是它应该指向的“C:\Program Files\SampleApp\sampleapp64.exe”。这两个二进制文件都存在于该文件夹中

这个问题给我们带来了一个真正的问题，因为应用程序调用了各种特定于体系结构的DLL（32位版本将使用32位DLL，64位应使用64位DLL）

安装程序需要根据用户的操作系统体系结构创建指向正确二进制文件的快捷方式

我接受了你的问题，因为我也有同样的问题

---

有人知道如何解决这个问题吗？谢谢

确实存在一个bug：安装程序将始终创建指向

sampleapp.exe

的链接，而不是指向

sampleapp64.exe

。这并没有人们预期的那么大影响。exe文件实际上只是启动JVM进程的一个小启动器。如果说JVM是64位的，那么不管启动器

.exe

是否实际上是32位二进制文件，都会得到64位的JVM。所以大多数人永远不会看到这个bug中的问题。但你可能是对的，如果你使用的是外部DLL，那么这可能是一个问题，不知道。我相信你的话，并提出解决办法

好的，那么真正重要的是您可用的JVM，而不是操作系统本身。我们可以在这里做出一个相当安全的假设：安装应用程序的JVM也将是最终运行应用程序的JVM。如果你把JRE捆绑在一起，这至少总是正确的，即使在其他情况下，这也是一个安全的赌注

为了修复，您必须使用NBI存根中自己的版本，因为这就是问题所在

在该文件中，您将看到底部附近

。。。
...
公共静态最终字符串可执行文件\u窗口=
本努细分市场
+ResourceUtils.getString（ConfigurationLogic.class，“CL.app.name”）+“.exe”//NOI18N

这需要按如下方式进行修复：

private静态字符串get64BitSuffix（）{
if（SystemUtils.isCurrentJava64Bit（））{
返回“64”；
}否则{
返回“”；
}
}
...
...
公共静态最终字符串可执行文件\u窗口=
本努细分市场
+ResourceUtils.getString（ConfigurationLogic.class，“CL.app.name”）+get64BitSuffix（）+get64BitSuffix（）+“.exe”；//NOI18N

---

现在谈谈如何在基于Maven的项目中使用自己的

ConfigurationLogic.java

：只需谷歌搜索即可。

您应该回答问题并接受它，而不是在标题中将其标记为“已解决”。