Post
by weinnir » Fri Apr 23, 2010 9:27 pm
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.