oWsh.Run works from dev machine not from client...

[thankgodfortektips]

Hi All,

I have a VB.exe that I want to give to my clients to help them dial a VPN... I have made the exe and from my machine it works great. However, once I move it to another machine it stops working. The VB.exe will load but when I try and run the following code, nothing happens...
********************
Dim oWsh
Set oWsh = CreateObject("WScript.Shell")
oWsh.Run "rasdial officevpn " & Me.txtUsername & " " & Me.txtPassword, 0, True
********************

Is there something that I need to include in the .exe?

Thank in advance...

 

[Andrzejek]

Yes, you need to run Package and Deployment Wizard to create an install package.

You have all needed pieces on your computer since you developed your app on it. Your users do not, so you need to provide all the pieces for them.

Have fun.

---- Andy

 

[BobRodes]

While Andy is of course quite correct, I would be careful using the P&D wizard, for various reasons that are well documented in other threads. Consider using the Microsoft Installer instead, or I see a good deal of good reports about "INNO Setup."

In any case, as Andy says, you do have to do something to package all the other files that your application depends on, dll's, ocx's and the like. Gone (LONG gone) are the days when you could just copy the exe to a disk and run it.

HTH

Bob

 

[Andrzejek]

Thank you Bob for kind word....

But maybe what thankgodfortektips needs is just a piece to run ("WScript.Shell"), whatever that is.

If everything else in his/her app is out-of-the-VB-box, it may just need this (little) piece to be installed on user machine?

Have fun.

---- Andy

 

[BobRodes]

Well, it's possible, but I don't think so. Either the OP has the reference to the "Windows Script Host Object Model" set or he doesn't. If he doesn't, he will get an error when he tries to run createobject, rather than nothing happening. If he does, then his rasdial.exe will run, and if there's something wrong in it, it could raise an error that gets buried.

I'm going to say that your initial assessment is correct, that there's a dll dependency required by rasdial.exe and the OP is failing to register that dependent file on the client machine.

Bob

 

[thankgodfortektips]

Hi guys,

Thanks for the quick response. So I can not just go to File, Make xxx.exe.

If I am understanding right I would have to create an installer package for the app. This is a very small app and wanted to avoid having to do that. Is there a way for me to check what the code is missing?

Thanks again!

 

[dilettante]

You might also try ditching the dependency. Here's a simple example. There are other ways too, such as writing a small routine to replace the VB6 Shell() function or the WshShell.Run() method.

Here I have a small script to run as the external process:

msgbox.vbs

MsgBox "Ready when you are...", vbOkOnly, "External Process"

Here is a small test program in VB6:

Form1.frm

Option Explicit

Private Const SYNCHRONIZE = &H100000
Private Const INFINITE = &HFFFF
  
Private Declare Function OpenProcess Lib "kernel32" ( _
    ByVal dwDesiredAccess As Long, _
    ByVal bInheritHandle As Long, _
    ByVal dwProcessId As Long) As Long
  
Private Declare Function WaitForSingleObject Lib "kernel32" ( _
    ByVal hHandle As Long, _
    ByVal dwMilliseconds As Long) As Long
  
Private Declare Function CloseHandle Lib "kernel32" ( _
    ByVal hObject As Long) As Long
    
Private Function SyncShell( _
    ByVal pathname As String, _
    ByVal windowstyle As VbAppWinStyle) As Boolean
    'Shell and wait.  Return True on any error.
    Dim lngPid As Long
    Dim lngHandle As Long
                 
    lngPid = Shell(pathname, windowstyle)
    If lngPid <> 0 Then
        lngHandle = OpenProcess(SYNCHRONIZE, 0, lngPid)
        If lngHandle <> 0 Then
            WaitForSingleObject lngHandle, INFINITE
            CloseHandle lngHandle
        Else
            SyncShell = True
        End If
    Else
        SyncShell = True
    End If
End Function

Private Sub Command1_Click()
    If SyncShell("wscript msgbox.vbs", vbNormalFocus) Then
        MsgBox "Failed to Shell msgbox.vbs"
    Else
        MsgBox "Success"
    End If
End Sub

Run the program. Click on Command1.

The program starts the script and waits for it to complete. The script runs and displays a MsgBox. When you click on the MsgBox's Ok button, the script exits.

The program resumes and displays its own MsgBox to indicate the completion of the external process.

 

[BobRodes]

While dilettante's code deserves proper recognition (nice piece of code!), it does NOT avoid dependencies in VB6. At the very least, you have to have the VB6 runtime dll for your programs to run. My suggestion is to get used to the "gone are the days" idea in my last post. DLLs are part of the fabric of every VB application. Period. Also, it is NOT a very small app. You just didn't write very much of the code.

Now that we've cleared all that up, if you want to check what code is missing, you can open up the Package and Deployment wizard and use the Create Dependency File option. This will list all the dependencies.

Best regards,

Bob

 

[dilettante]

I only raised the issue because this is not a normal dependency one would try to install as part of a program's setup/installer. I'm not sure Microsoft ever released a merge module for it, since "it" is basically all of Windows Scripting.

It's hard to imagine a machine that doesn't have WSH and Scripting installed already. But if one wanted to run a program on such a moldy beast it would be better to avoid such a large dependency.

 

[BobRodes]

Well, perhaps so. But it isn't so hard to imagine a machine that doesn't have the VB6 runtime DLL installed, even ones that aren't so very moldy. And if you don't have that, why the OP's program won't run either. That's MY point.

Bob

 

[dilettante]

Well I absolutely agree that a setup/installer should be used. I was simply suggesting avoiding Windows Scripting here. I'd hate to see the OP get frustrated trying to deploy the Script Host Object Model dependency along with everything else it requires in turn.

 

[BobRodes]

See, dilettante, when you said "you might also try ditching the dependency" my vast experience as an instructor caused me to feel that the OP would get the impression that you were explaining to him how to avoid using an installer (especially since he clearly doesn't want to), and I wanted to disabuse him of that notion.

 

[dilettante]

Fair enough.

There are times when you can XCopy-deploy VB6 programs just fine, but as a general rule you need to know what you're up against and take responsibility when it falls over. Thus the practice should be considered an exception.

For that matter so many things were fixed and tweaked by the time VB6 SP6 came out you're probably better off not relying on whatever components happen to be sitting on a given target machine anyway.

Basically, I find myself in violent agreement with you on this. ;-)

 

[BobRodes]

Yup, I can tell.