Page 2 of 2

Re: Remote execution issue

Posted: Thu Apr 22, 2010 1:31 pm
by Support Team
Hi weinnir!

There is a possible workaround for this issue. You have to start the AUT in your Ranorex Application
System.Diagnostics.Process.Start(@"pathToExe");
We suspect that Windows Security causes the problem, because it seems that the process started by the PsExec services is not allowed to hook into the AUT process.

Hope the workaround helps.

Regards,
Peter
Ranorex Support Team

Re: Remote execution issue

Posted: Fri Apr 23, 2010 4:19 pm
by weinnir
I actually had this piece of code in my Ranorex main for the complete test.
I used it to verify whether the app is already running or not, in case of it not running I would then launch it.
The launching part works fine (as it was before) but it still fails identifying any component in the form

Re: Remote execution issue

Posted: Fri Apr 23, 2010 5:15 pm
by Ciege
What version of windows is having the issue? I am now wondering (if it is Vista or 7) that it could be a UAC or similar security complication.

If Vista or 7 make sure you have the latest PSExec and try the -h switch.
-h If the target system is Vista or higher, has the process run with the account's elevated token, if available.
http://serverfault.com/questions/72556/ ... -interacti

Also you can try changing the session ID from 0 to 1 using -i 1
http://84.45.57.224/psexec-windows-7_topic19020.html

Re: Remote execution issue

Posted: Fri Apr 23, 2010 5:22 pm
by weinnir
I'm using XP Pro SP3. I've also disabled the security suite on that machine just to be sure.

Re: Remote execution issue

Posted: Fri Apr 23, 2010 9:27 pm
by weinnir
OK, there's some progress in this case:
I'm now able to run the automated test from a remote machine using psexec, the Ranorex exe identifies the controls in the form and everything works great.
HOWEVER, I found the culprit that won't let me do so in a real development environment.
Right now I'm using the Ranorex team suggestion of launching the AUT from within the Ranorex code using Process.Start however, and this might be the problematic part - Our application is a ClickOnce application, and as such it's real exe location is not permanently in the same location (deep down in the Local Settings\Apps folder with ever-changing temp folder names).
So launching the AUT from the Ranorex's code while hard-coding the exact exe location of the ClickOnce app works, but this is not a real solution as I cannot know the real location of the executable each and every time there's a new build. Moreover, this technique only works when I'm launching the application from the start; in my test suite I don't always launch the application (in fact I never do, only when the application is not running), so running the tests would require me to launch the application every single time - something that is very not desirable and would slow down the entire process significantly.

I've tried using the process.start with the UNC address (the ClickOnce is on a network drive, not an absolute URL) of the application which in turn launched the application but never recognizes any controls, or even with the Start menu shortcut i.e. C:\Documents and Settings\userName\Start Menu\Programs\companyName\AppName.appref-ms but still same result.

Getting to a point where I can run my tests is good, but the current workaround is very insufficient - for all the reasons above.