VB.NET 2008 Deployment always Crashes

[vbahuse]

Hello all,

I'm new to .NET but have experience in Visual Basic 6.0

I have recently written an application in VB.NET 2008 Express which uses a reference to the old mswinsck.ocx instead of the new sockets stuff. The application works great on the machine it was developed on, however when I attempt to install it on any other computer (used the Publish feature) it always crashes and gives a message box asking the user to send an error log to Microsoft.

The application also generates two log files (one for logging data from the sockets connection and the other for debugging purposes). When the app has been deployed neither log file gets generated so I can't even determine how far it gets or where it dies!

Questions:

1. Has anyone seen this before and how did you solve it?

2. Where is the local application path on the deployed machine? (i.e. where would my log files be generated?)

Thanks,

vbahuse

 

[vbahuse]

Additional Information:

I should mention that we have ordered Visual Studio .NET 2008 Professional. I'm hoping that this is purely a limitation with using the free version because I need to formally deploy this app to a few employees very soon.

vbahuse

 

[RiverGuy]

If you go to the properties of your project, under the "Publish" tab, you will see some options for things like "Application Files" and "Prerequisites." These will come in useful.

One thing Visual Studio Professional will give you will be the ability to create a traditional Windows installation. You gain more flexibility over Click-Once Deployment (Publishing), but you lose the ease of use of things like making application updates seamless.

 

[vbahuse]

Thanks for the reply RiverGuy,

I've taken a look at the Application Files and Prerequisites as you mention however they look fine to me. That is, the test machine I'm deploying to meets the Prerequisites and the Application Files shows what I would expect to see (Interop.MSWinsockLib.dll and an icon file as Required).

I've done a bit more investigation and found the install log file in the Temporary Internet Files directory which shows everything as successfully completed for the install. So it looks like the install is good but the app just dies at startup.

My guess is that it either has to do with the legacy Winsock reference or the log file handling, I check for a sub directory called Logs in the My.Application.StartupPath and create if not there.

vbahuse

 

[vbahuse]

Another update!

At home I have a machine running WinXP Pro w/ SP3 and .NET 3.5 installed. It also has Visual Studio 6.0 Pro and the new .NET click-once application installs and runs fine on it! First machine since the one I developed it on! This gives me hope that the issue is most likely the legacy MSWINSCK reference?

The error information on any of the machines at work that I have tried is as follows:

Exception Information
Code: 0xE0434F4D Flags: 0x00000001
Record: 0x0000000000000000 Address: 0x000000007C812A5B

Anyone? Please?

 

[Sorwen]

I have no direct clue on how to help, but let me say two problems I ran into in the past and this was with 2005. A click-once installation does not register files in correct way for every file type. There are three (two kind of related) problems this could cause. One is if MSWINSCK is already registered on the machine it might cause a conflict. I had this happen with another dll I was using. The other two problems are if it is not registered correctly. It might not have the permissions required to run correctly from the directory and/or even though the program will look in the local directory because the nature of the file it could be expecting it to be in the system folder.

I hope that will maybe help. It get a little into things I only know the edges of so I may not have explained that right. Any way that was some of the problems I had with deployment. On the first instance it is just a matter of excluding the file and not letting it be deployed on the second two you have to install/register (loaded to the GAC not through click-once) the file separately.

-I hate Microsoft!
-Forever and always forward.
-My kingdom for a edit button!

 

[jebenson]

Have you verified that mswinsck.ocx is being copied to the target machine? I mean by actually looking in the directory where it is supposed to be installed, not just looking at the log file? If is is there, try running regsvr32 to register the ocx, then try running your application again. If it is not there, try manually copying mswinsck.ocx over and doing regsvr32. If this works, at least you will know what is going wrong and can then address the issue.



I used to rock and roll every night and party every day. Then it was every other day. Now I'm lucky if I can find 30 minutes a week in which to get funky. - Homer Simpson

Arrrr, mateys! Ye needs ta be preparin' yerselves fer Talk Like a Pirate Day!

 

[vbahuse]

Okay, I've tried the following:

1. Uninstalled the application from the control panel, add/remove software.

2. Manually unregistered the mswinsck.ocx file and then deleted it from the windows system32 directory

3. Re-installed the application with the click-once setup.exe (no mswinsck.ocx file was placed in system32, which I beleive is correct because it places an Interop.MSWinsockLib.dll file in the local install directory) -- Application still crashes

4. Grasp at straws! I copied the Interop.MSWinsockLib.dll to the system32 directory and tried to manually register it but received the error "Interop.MSWinsockLib.dll was loaded, but the DllRegisterServer entry point was not found. This file cannot be registered."

5. Grasp at straws V2.0! I copied mswinsck.ocx to the system32 directory and manually registered it -- Application still crashes!

As I mentioned in point 3. I don't believe .NET looks for the actual mswinsck.ocx file and relies soley on the Interop.MSWinsockLib.dll placed in the local program directory.

Out of ideas!

 

[RiverGuy]

Option 6. -- Rewrite your application to use managed TCPClient/TCPListener

 

[vbahuse]

Yes, yes, I know! I have yet to delve into multi-process application writing, but you are very correct, I shouldn't be using a relic ocx reference for any .NET programming.

It just bothers me when things work in one spot but not in another without a good explaination.