Problem with Windows 64 bit

[neologica]

Hi,

We are experiencing some very odd behaviors using an installer on Windows 64bit, built with InstallAnywhere 2008 and having a custom action that downloads a Zip file from a http server.

First of all if I had installed the 64bit jre only, then the installer doesn't start at all.
The strange fact is that the error message is different for different version of Windows.
Error on WinXp 64bit: http://img29.imageshack.us/img29/8413/errornovmwinxp64.png

Error on Windows 7 64bit: http://img97.imageshack.us/img97/251/errornovmwin7.png

So we built an installer containing a jvm to make it run.
This way it starts but the custom action fails throwing an error, again based on the version of Windows.
This is the error we get:

Win7 64bit:

Additional Notes: FATAL ERROR -     class localeyenetinstaller.LocalEyeInstaller FatalInstallException: Protocol wrong type for socket: create

WinXp 64bit:

Additional Notes: FATAL ERROR -     class localeyenetinstaller.LocalEyeInstaller FatalInstallException: Unrecognized Windows Sockets error: 10106: create

We don't get why we have this error because on a 32bit machine everything works flawlessy.

The code used for the custom action is very simple:
[CODE]
URL url = new URL("http://someServer/someFile.zip");
File tmpFile = File.createTempFile("file", ".tmp");
if (tmpFile.canWrite())
{
FileOutputStream fileOutStream = new FileOutputStream(tmpFile);
java.io.InputStream inputStream = url.openStream();
byte [] buffer = new byte[1024 * 32];
int readLen = 0;
while ((readLen = inputStream.read(buffer)) != -1)
{
fileOutStream.write(buffer, 0, readLen);
}
fileOutStream.close();
inputStream.close();
return tmpFile;
}
else
{
return null;
}
[/CODE]

And this is the stack trace:

java.net.SocketException: Protocol wrong type for socket: create
	at java.net.Socket.createImpl(Unknown Source)
	at java.net.Socket.connect(Unknown Source)
	at java.net.Socket.connect(Unknown Source)
	at sun.net.NetworkClient.doConnect(Unknown Source)
	at sun.net.www.http.HttpClient.openServer(Unknown Source)
	at sun.net.www.http.HttpClient.openServer(Unknown Source)
	at sun.net.www.http.HttpClient.(Unknown Source)
	at sun.net.www.http.HttpClient.New(Unknown Source)
	at sun.net.www.http.HttpClient.New(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
	at java.net.URL.openStream(Unknown Source)
	at ZeroGil.saveURLContentToFile(DashoA10*..)
	at com.zerog.ia.api.pub.InstallerProxy.saveURLContentToFile(DashoA10*..)
	at localeyenetinstaller.LocalEyeInstaller.install(LocalEyeInstaller.java:55)
	at com.zerog.ia.installer.actions.CustomAction.installSelf(DashoA10*..)
	at com.zerog.ia.installer.InstallablePiece.install(DashoA10*..)
	at com.zerog.ia.installer.InstallablePiece.install(DashoA10*..)
	at com.zerog.ia.installer.GhostDirectory.install(DashoA10*..)
	at com.zerog.ia.installer.InstallablePiece.install(DashoA10*..)
	at com.zerog.ia.installer.Installer.install(DashoA10*..)
	at com.zerog.ia.installer.actions.InstallProgressAction.n(DashoA10*..)
	at com.zerog.ia.installer.actions.ProgressPanelAction$1.run(DashoA10*..)

The strangest thing is that, even though I had a 32bit jre installed on a 64bit OS the installer fails anyway throwing the same error.
But if I run the code using a simple java application then it runs smoothly.

I repeat myself a little just to say that on Windows 32bit with jre 32bit everything works

Hints ?

[pv7721]

Is this issue different from what you've posted here: http://community.flexerasoftware.com/showthread.php?t=191607 ?

[neologica]

The issue is different. In the other post we were complaining about the lack of support on 64bit machines. (The installer didn't start at all).

In this case we are trying to understand what can cause the error above, on a 64bit pc having the 32 bit jre installed.

[Frenchy]

I am having the same issue, does anyone have a solution for this?

I have added a host with the correct database name server name user and password. I let IA pick the driver class

net.sourceforge.jtds.jdbc.Driver

Do I have to add the jtds-1.2.2.jar to my install? Where to I install it to? This is only needed during install time. Should the custom driver settings check-box be checked? If anyone can help me it would be appreciated. thank you

=========================================================

Install Action: SQL Script 'config.sql' (MS SQL Server)
Status: ERROR
Additional Notes: ERROR - ZeroGaf8 - An error occurred while trying to establish a connection with the database server: Network error IOException: Protocol wrong type for socket: create

[pv7721]

Normally, when you use the Execute Custom Code action you specify the class but also the PATH to the .jar / .zip file containing the class... Thus the respective .jar is automatically included in the installer but it is not installed anywhere (most likely it is used only temporarily during install time, from the unzipped installer's resources).

[mbulhoes]

Did you ever resolve this issue? I'm having the same problem.

thanks
mb

[reachlin]

Hi,
We also got this "protocol wrong type" error when using httpconnection. But the problem doesn't show in the gui install mode. It only happens at the silent install mode. The env., or JVM are exactly the same.

Please help......

[Roddo99]

The problem I had was that the "protocol wrong type for socket create" message would appear when connecting the a SQL Server driver using custom code action.

Worked perfectly in 32 bit, failed in 64 bit. In 64 bit worked perfectly outside of IA.

In any case, the solution was to move the action out of the install tab and into pre or post install. In this case, I moved the action to the very beginning of post-install. Horrid hack, but appeared to work.

Hopefully Flexera acknowledges the issue and solves it properly.

[eciramella]

I too am now hitting this problem, but we're not doing any custom anything. We're using the standard "Execute SQL" actions (which can't be moved to the "post install phase").

Anyone have any valid workarounds or know if upgrading to 2010 solves this? We're using 2009 Enterprise Edition SP1.

[cjohannessen]

We're having the same problem running Execute SQL commands on Server 2008 R2. I can confirm this problem still exists in the 2010 version. This is terrible since we are unable to progress on our installation project.