Timeout of FileUpload control using VS2010 TFS (C# with Selenium) with AutoIt

[geedubya]

Hi all.

We're using AutoIt with VS2010 TFS (C# with Selenium) to test, and then to deploy (& regression test) our webapp.

We introduced AutoIt as a way to access the ASP.Net FileUpload control, as Selenium can't for security reasons.

This code snippet demonstrates what we're doing (we use C#, not Java).

This works great locally, but when we deploy via TFS, the test times-out on the system test environment.

My code is similar to the above snippet, but with logging due to the problems we've been having:

• My my C# test executes a stand-alone AutoIt exe (passing one parameter)
• AutoIt then waits for the window titled Choose File to Upload to open
• AutoIt fills in the filepath/name ($CmdLine[1])
• AutoIt fires Enter to close the dialog and returns control to my C# test

#include <Date.au3>

My actual code:

IPVLog("Start")

WinWaitActive("Choose File to Upload")

IPVLog("After WinWaitActive")

Send($CmdLine[1])

IPVLog("After send text: " & $CmdLine[1])

Send("{ENTER}")

IPVLog("End")

Exit

Func IPVLog($text)

$file = FileOpen("IVPAutoItLog.txt",1)

If $file = -1 Then

; MsgBox(0, "Error", "Unable to open file.")

Exit

EndIf

$tTime = _Date_Time_GetSystemTime()

FileWriteLine($file, _Date_Time_SystemTimeToTimeStr($tTime) & " " & $text & @CRLF)

FileClose($file)

EndFunc

Locally, everything runs.

On System Test, IPVLog("Start") executes, but it times out on the WinWaitActive("Choose File to Upload") step. The TFSBuild user is executing the tests on System Test.

So to summarise, Selenium seems to be doing it's job in both environments, but AutoIt isn't picking up the Choose File to Upload dialog on the System Test environment.

Any ideas anyone?

Thanks in advance

Geedubya

[PsaltyDS]

This is how I would have done that:

#include <File.au3>

Global $sLogFile = "IVPAutoItLog.txt", $hWnd

If $CmdLine[0] Then
    _FileWriteLog($sLogFile, "Start")

    $hWnd = WinWaitActive("Choose File to Upload", "", 60) ; 60sec timeout
    If $hWnd Then
        _FileWriteLog($sLogFile, "After WinWaitActive:  $hWnd = " & $hWnd)

        ControlSend($hWnd, "", "", $CmdLine[1], 1)
        _FileWriteLog($sLogFile, "After send text: " & $CmdLine[1])

        ControlSend($hWnd, "", "", "{ENTER}")
        _FileWriteLog($sLogFile, "After Enter")
    Else
        _FileWriteLog($sLogFile, "WinWaitActive() timeout.")
    EndIf
EndIf
    _FileWriteLog($sLogFile, "Error, no parameter received.")
EndIf

You didn't mention possible differences in OS, user privilege level, etc. that might be present.

[geedubya]

This is how I would have done that:

#include <File.au3>

Global $sLogFile = "IVPAutoItLog.txt", $hWnd

If $CmdLine[0] Then
    _FileWriteLog($sLogFile, "Start")

    $hWnd = WinWaitActive("Choose File to Upload", "", 60) ; 60sec timeout
    If $hWnd Then
        _FileWriteLog($sLogFile, "After WinWaitActive:  $hWnd = " & $hWnd)

        ControlSend($hWnd, "", "", $CmdLine[1], 1)
        _FileWriteLog($sLogFile, "After send text: " & $CmdLine[1])

        ControlSend($hWnd, "", "", "{ENTER}")
        _FileWriteLog($sLogFile, "After Enter")
    Else
        _FileWriteLog($sLogFile, "WinWaitActive() timeout.")
    EndIf
EndIf
    _FileWriteLog($sLogFile, "Error, no parameter received.")
EndIf

You didn't mention possible differences in OS, user privilege level, etc. that might be present.

Thanks - I'm new to AutoIt, so I'll see what your code's doing and take it from there

Cheers

Graham

[geedubya]

Hi

This is what I'm running now:

#include <File.au3>

Global $sLogFile = "IVPAutoItLog.txt", $hWnd

If $CmdLine[0] Then

_FileWriteLog($sLogFile, "Start")

$hWnd = WinWaitActive("[CLASS:#32770]", "", 60) ; 60sec timeout

If $hWnd Then

_FileWriteLog($sLogFile, "After WinWaitActive: $hWnd = " & $hWnd)

ControlSend($hWnd, "", "Edit1", $CmdLine[1], 1)

_FileWriteLog($sLogFile, "After send text: " & $CmdLine[1])

ControlSend($hWnd, "", "", "{ENTER}")

_FileWriteLog($sLogFile, "After Enter")

Else

_FileWriteLog($sLogFile, "WinWaitActive() timeout.")

EndIf

Else

_FileWriteLog($sLogFile, "Error, no parameter received.")

EndIf

I've tried several variations, i.e.:

• $hWnd = WinWaitActive("Choose File to Upload", "", 60) ; 60sec timeout
• $hWnd = WinWaitActive("[CLASS:#32770]", "", 60) ; 60sec timeout

All are fine locally - the log file has:

2011-07-07 16:24:18 : Start

2011-07-07 16:24:32 : After WinWaitActive: $hWnd = 0x000419B2

2011-07-07 16:24:33 : After send text: z:\Projects\NPD001-Chertsey\SSISSourceData\UploadResults.xlsx

2011-07-07 16:24:33 : After Enter

However, again on our system test environment, we get a timeout

2011-07-07 17:04:45 : Start

2011-07-07 17:05:45 : WinWaitActive() timeout.

Our TFSBuild User is able to execute the script, and pass the parameter in, but the WinWaitActive can't seem to get a handle on the control

Has anyone tried anything similar, or does anyone have any further suggestions?

Thanks

Geedubya

[PsaltyDS]

Do local and test environments match for OS version and is TFSBuild User running it under the same perms on each?

[geedubya]

Do local and test environments match for OS version and is TFSBuild User running it under the same perms on each?

If I run the test manually from from the Visual Studio interface on the build environment, it works fine - I can see the text being typed into the control as per if i'm running it locally. I think that suggests that it's not a problem with the actual privileges themselves. I'll get the user privileges checked out, but I think the build user on the test environment will have similar privileges to the ones I have locally.

However if I deploy a build via Visual Studio (where the test are run at the end), then AutoIt (WinWaitActive) always times out - I can see this via a log file, plus the control sits there, but isn't written to.

This is the DeployRemoteCommand for the build in Visual Studio:

-i 0 -h -u BRIDGEALL\build.user -p <password> "C:\windows\System32\WindowsPowershell\v1.0\PowerShell.exe" -ExecutionPolicy Bypass

I'm baffled . . .

[geedubya]

The build user has full administrator permissions.