在使用Izpack 5 Beta 11的测试机器上,如果我使用运行捆绑的64位java的64位winrun4j exe启动install.jar,那么Izpack会抱怨
There is no script engine for file extension ".js"
,
抱怨The installer could not launch with administrator permissions
,
然后尝试安装到默认安装目录失败,因为您没有管理员权限,安装到C:/ Program Files之外的另一个文件夹完成正常
然而,如果我使用运行32位java的32位winrun4j安装程序运行它,它可以正常工作。
如果我只是在没有exe包装器的情况下直接运行install.jar
即java -jar install.jar
它使用32位JVM和64位JVM提供这些错误。
所以我目前唯一可行的解决方案是使用32位exe包装器进行安装,但我还需要64位包装器。
所以问题是
跟进
我发现this thread有关javascript错误(但不是Izpack),并发现.js文件与Utlradedit相关联,Utlradedit是我用来编辑大多数文件类型的编辑器。
简单地将.js与Ultraedit无关联意味着现在我运行时
它现在有效:)
但64位winrun4j现在无法启动安装并且根本无法工作,如果我从命令窗口运行,我可以看到
正在运行
wscript C:\Users\MESH\AppData\Local\Temp\Installer.js
c:\Code\WidgetReleases\1.0_Beta_2\widget-windows64\JVM64\bin\javaw.exe
-Dizpack.mode=privileged -jar
C:\Code\WidgetReleases\1.0_Beta_2\widget-windows64\install.jar
他们跑了
wscript C:\Users\MESH\AppData\Local\Temp\Installer.js
c:\Code\WidgetReleases\1.0_Beta_2\widget-windows64\JVM64\bin\javaw.exe
abort exit
-Dizpack.mode=privileged -jar
:\Code\WidgetReleases\1.0_Beta_2\widget-windows64\install.jar
所以跟进问题是:
答案 0 :(得分:3)
这里有四个问题:
我会尝试回答他们:
错误和错误有时在程序中应该“无缝地”处理32位和64位;一个例子是赛门铁克的SEP定义修复程序 - 它有时可以工作但不是全部。你的评论确认了这些错误,你甚至发现了一个在32/64处理中没有错误的竞争程序:“没有解决这个问题,但是通过使用launch4j而不是运行安装程序解决了这个问题winrun4j”。恭喜! :)
我怀疑必需的app / wrapper不在你系统的PATH中。路径中的两个文件夹是C:\ WINDOWS和C:\ WINDOWS \ SYSTEM32。在命令提示符下,键入单词SET
(不需要上限)。出现按字母顺序排序的变量列表。在一个说PATH =寻找你希望启动你的应用程序的包装器的完整文件夹路径的那个。它可能不存在。如果您愿意,可以添加它。
很好的问题,但有一个很好的理由:通过将文件类型与程序关联打开,您告诉计算机始终使用文件编辑器打开文件,在本例中以.js结尾。它正在做你告诉它做的事情,而不是你想要的。获得预期的一种流行方式是将文件与之前的程序重新关联(您可能知道哪个是最好的),并编辑文件,将您喜欢的JS编辑器添加到Windows资源管理器右键菜单中的“打开方式...”选项。如果你愿意的话,我可以找到并链接到一两页如何做到这一点。
我认为这与问题和答案#1密切相关。
如果有帮助,请告诉我。
答案 1 :(得分:0)
更改.js文件的默认操作会导致问题,原因与更改.exe文件的默认操作会导致问题的原因相同。程序希望另一个程序的默认操作是运行它。编辑应始终是右键单击操作,而不是默认操作。