32/64 bit questions : General Questions

[Ciege]

OK, just got my first 64bit Windows 7 machine up for automation purposes. It is using a runtime only license so I am unable to use Spy to check any xPaths or recognition.

Here is my working scenario. I have my Ranorex Premium on a 32bit XP machine. I have written a Launcher for my runtime machines that will do the following:
1) Using PSEXEC build the script on the development machine (using Visual Studio's devenv.exe command line utility and setting the target to "Any CPU").
2) Copy the resulting build folder (with all the appropriate DLLs) to the local runtime machine.
3) Launch the EXE of the test locally on the runtime machine.

I've been running this scenario for a very long time with a Windows 7 32bit machine with no problems. However, now that I am running my automation from a 64bit machine I am getting strange, unexpected object not found exceptions that I am 100% unable to reproduce on my 32bit machines.

Q1) Since this is failing on a runtime machine is there anything I can do to try and verify the recognition of objects is working? I can't use Spy obviously.
Q2) When launching a test via an EXE on the 64bit runtime machine is it possible to tell it to run using the 64bit version of Ranorex? Or, since it is built on a 32bit machine is it always going to run the 32bit version of Ranorex?

[Support Team]

ad Q1) That is usually what a floating license is used for. Alternatively, you can create a snapshot of the problematic element on the runtime machine - as you explained in following post
how-to-create-snapshot-file-using-script-t1583.html#p5825

ad Q2) Whether a .NET EXE is launched as a 64 or 32 bit process, depends on the target framework it is compiled to:
AnyCPU -> 64 bit process
x86/32bit -> 32 bit process
x64/64bit -> 64 bit process

Please, read following section in the Ranorex User Guide for recommendations on testing of 64 bit operating systems:
http://www.ranorex.com/support/user-gui ... forms.html

Regards,
Alex
Ranorex Team

[Ciege]

That is usually what a floating license is used for.

Well, we don't have any floating licenses... Have been node locked licensed for longer than floating licenses have been available...

Alternatively, you can create a snapshot of the problematic element on the runtime machine - as you explained in following post
how-to-create-snapshot-file-using-script-t1583.html#p5825

Forgot about that! I'll give it a go.

Whether a .NET EXE is launched as a 64 or 32 bit process, depends on the target framework it is compiled to:

well, I've compiled using Any CPU as well as the default 32bit. Both work on my 32bit machines and neither work on my 64bit machine...

Please, read following section in the Ranorex User Guide for recommendations on testing of 64 bit operating systems:

I've read and re-read the guide. Nothing there seems to fix my issue. Since I am running on a Runtime only license I'm not even sure I can open Spy or Studio to verify the status of the bit bridge (but am assuming it is enabled since I've done nothing that I know of specifically to disable it).

[Ciege]

OK... Here are the 32bit and 64bit snapshots of the dialog that is failing. There are obvious differences in the xPaths for each.

32bit.rxsnp

(198.88 KiB) Downloaded 16 times

64bit.rxsnp

(220.7 KiB) Downloaded 14 times

Also, I get this message in my log.

RanorexLog64.jpg (57.53 KiB) Viewed 232 times

[Support Team]

There are obvious differences in the xPaths for each.

That's understandable if there is a problem with the Ranorex Bit Bridge as stated in the report. The problem is that the Bit Bridge cannot be contacted. There are usually only two causes for this:

• Ranorex is not installed correctly (please re-install); or with copy & paste deployment not the whole "bin" folder (including sub-directories) was copied to the target machine.
• There is a security problem or firewall/anti-virus software not allowing Ranorex to communicate with the Bit Bridge. As we use an IPC channel (local pipes) this is rather unusual. Do you start the process with administrative rights? Do you have UAC turned on? Is an anti-virus/firewall software installed?

Anyway, you might not even need the Bit Bridge, since from your snapshot it looks like your application is running as a 32 bit process on the 64 bit OS as well (you did create the snapshot with an "AnyCPU" compiled EXE, right?). As outlined in the user guide, it is generally better to target the same target CPU as the AUT with the test executable (for performance and special compatibility reasons). So please, set the target CPU for your test executable project to "32 bit" (all DLL projects should stay on "Any CPU"), then Ranorex should be able to recognize your application again even without the Bit Bridge.

Regards,
Alex
Ranorex Team

[Ciege]

Ranorex is not installed correctly (please re-install)

I will try installing again, but it doesn't seem that it is likely the issue since things run fine up until this particular dialog. This script that I am running is an installation script that goes through our installers. several of them start off running fine until this dialog then it fails with object not found exceptions (noted in the snapshot discrepancies).

or with copy & paste deployment not the whole "bin" folder (including sub-directories) was copied to the target machine.

I'm assuming you mean with the copy/paste of the compiled test scripts. In this instance, I build in debug. so the only folder structure under Bin is /Debug. When copying the compiled test over the entire debug folder and substructure are all copied over. Remember, this all works fine on my 32bit test machines using this exact method.

There is a security problem or firewall/anti-virus software not allowing Ranorex to communicate with the Bit Bridge

I will check this as I was not the one who installed the machine.

Do you start the process with administrative rights?
Do you have UAC turned on?
Is an anti-virus/firewall software installed?

The user running the scripts is an admin but we did not try specifically right-clicking and selecting "run as admin" as this proved unnecessary on the 32bit Windows7 machine.
UAC has been disabled as much as possible, again mimicking the 32bit machine.
AV/Firewall will need to be checked.

So please, set the target CPU for your test executable project to "32 bit" (all DLL projects should stay on "Any CPU"), then Ranorex should be able to recognize your application again even without the Bit Bridge.

I've tried compiling using the command line as default (which is 32bit) but I will expressly call that out next time and try it. I've also compiled as Any CPU with the same issues.


So, I'll go through some of these tests today and report back with what I find.

[Ciege]

OK, I have done the following:
1) Reinstalled Ranorex
2) Verified everything required to run a script is copied over properly
3) Disabled firewall
4) Verified no AV is installed
5) Verified UAC is disabled
6) Set the scripts target CPU to 32bit
7) Ran the script "as administrator"

I did not get the bit bridge message this time, however, according to the snapshot I took with all of the above settings, the same discrepancies for object recognition still exist. They look the same as the snapshot for 64bit attached earlier in this thread.

I don't understand why the path differences when moving from 32bit to 64bit. Is this "just the way it is" when making the move or is this an issue with Ranorex?

[Support Team]

I don't understand why the path differences when moving from 32bit to 64bit. Is this "just the way it is" when making the move or is this an issue with Ranorex?

No, this is not normal. With the Bit Bridge working correctly you should not see a difference whether you run on a 32 bit or 64 bit machine.
That said, if both your test executable and the AUT run using the same bit width, then the Bit Bridge should not be needed at all. So, if the element recognition is still not working correctly, even after you made sure both AUT and test process run as 32 bit processes, then something else is limiting the object recognition (and not the 64/32 bit interoperability).

Do you get any technology limitation warnings in your report?
Please, make sure that none of the reasons listed in the following Ranorex User Guide section applies:
http://www.ranorex.com/support/user-gui ... html#c3250

Regards,
Alex
Ranorex Team

[Ciege]

So I made a couple of code changes in my automation code to support the differences in the xPaths for the installer dialog I was having issues with. I have passed that point and can successfully install my AUT properly. However, now many/most of the xPaths in my actual AUT also have the differences in xPath recognition with the Element-ControlName set as the parent object to the object I want to deal with rather than having the xPath to the object itself as the parent.

Here is one example:
32bit:

Code: Select all

/form[@controlname='frmMainDialog']/menubar[@controlname='mMenu']/menuitem[@accessiblename='File']

64bit:

Code: Select all

/form[@controlname='frmMainDialog']/element[@controlname='mMenu']/menubar/menuitem[@accessiblename='File']

As you can see this will cause 100% of my 3 years of code to fail...

Do you get any technology limitation warnings in your report?

No, none whatsoever.

Reason #1:
The automating process (Ranorex executable) and the automated application (AUT) are not started with the same security rights, i.e. not as the same Windows user.

Everything is started by the logged in user. Who is a domain admin AND a member of the local computer Administrators group.

Reason #2:
Either the automating executable or the AUT are started from a network drive or encrypted folder and consequently do not have the required security rights.

Everything is copied to and launched from the local drive.

Reason #3:
The controls that cannot be identified are implemented in a mixed-mode EXE file (not DLL). This can be the case with some obfuscating applications or assembly merging utilities that create mixed-mode EXE files. The .NET Framework does not support loading such mixed-mode executables in other processes and that's why Ranorex cannot recognize controls implemented within them.

Not the case here. It works properly with the same automation code and same AUT on 32bit windows.

Reason #4:
The controls that cannot be identified are implemented in an assembly that targets a particular platform/processor and the automating executable targets a different platform/processor. This can cause problems on 64 bit operating systems, since such assemblies cannot be loaded by the automating process.

I've tried this already. It didn't seem to make a difference. Changed Target from Any CPU to x86 with no differences.

Reason #5:
The .NET Framework 4.0 Extended package is needed but not installed. An indication for this problem typically is that controls can correctly be identified by the standalone Ranorex Spy application, but not by the integrated Ranorex Spy or Recorder in Ranorex Studio. The application under test uses the .NET Framework 4.0 and you may get Technology Limitation pop-ups saying that specific assemblies cannot be loaded.

The AUT is not .NET 4, however, the .NET 4 Framework and Extended are both installed on the 64bit machine.

Reason #6:
If the application under test is built with the .NET Framework 4.0, a <executableName>.exe.config file (where <executableName> has to be replaced by the name of the Ranorex executable) needs to reside in the same folder as the automating Ranorex executable and it needs to contain the configuration below.

Same as #5, this is not a .NET 4 AUT.

[Ciege]

Well now....
After going through the troubleshooting list I see that Reason #5 & #6 both make mention of .NET 4. And, even though my AUT is not a .NET 4 application it seemed that the only difference (other than 32/64 bit) between the machines was the installation of the .NET 4 Framework and Extended...

Sooooo, I uninstalled them both and Lo and Behold... xPath recognition is now back to as I would expect it to be...

Can you explain this? This will be a problem for me as going forward I will be testing another AUT that requires the .NET 4 framework on the same machine as the my original AUT that uses the .NET 3 framework.

Hmmm...

[Support Team]

So I made a couple of code changes in my automation code to support the differences in the xPaths for the installer dialog I was having issues with.

Please, don't! The differences in the RanoreXPaths are not normal and due to some object recognition problem that has to be fixed first. Do you get any warnings in your report?

And, even though my AUT is not a .NET 4 application it seemed that the only difference (other than 32/64 bit) between the machines was the installation of the .NET 4 Framework and Extended...

Are you sure your AUT does not use .NET 4 if it is available? Even if not build for 4.0, you can set up an application to use the new 4.0 Runtime if it is available (Ranorex does the same in order to make .NET 4.0 applications recognizable).

You can check whether the application uses .NET 4.0 by installing the .NET 4.0 Framework (Client + Extended Profile) and then try to attach to the process using Visual Studio. If you use VS 2008 and the process does not show up as "Managed" or you use VS 2010 and the process shows up as ".NET 4.0", then you know that the AUT indeed uses the .NET 4.0 Runtime. And then you have to consider "Reason #6" in the trouble shooting section.

Regards,
Alex
Ranorex Team

[Ciege]

Are you sure your AUT does not use .NET 4 if it is available? Even if not build for 4.0, you can set up an application to use the new 4.0 Runtime if it is available (Ranorex does the same in order to make .NET 4.0 applications recognizable).

You can check whether the application uses .NET 4.0 by installing the .NET 4.0 Framework (Client + Extended Profile) and then try to attach to the process using Visual Studio. If you use VS 2008 and the process does not show up as "Managed" or you use VS 2010 and the process shows up as ".NET 4.0", then you know that the AUT indeed uses the .NET 4.0 Runtime. And then you have to consider "Reason #6" in the trouble shooting section.

OK, reinstalled .NET4 framework + Extended.
Verified that the object recognition xPaths were indeed different again.
Launched VS 2008 and checked the Type of my AUT when Attaching to the Process.

My AUT shows up as Managed.

Managed.jpg (69.07 KiB) Viewed 184 times

[Ciege]

And by the way...

Please, don't! The differences in the RanoreXPaths are not normal and due to some object recognition problem that has to be fixed first. Do you get any warnings in your report?

My code changes were temporary to get past the portion of the installer just in case it was just an issue with the installer.

And no, I get no warnings in my report.

[Support Team]

Launched VS 2008 and checked the Type of my AUT when Attaching to the Process. My AUT shows up as Managed.

There goes my last idea, I really thought your AUT used .NET 4.0

OK, back to trial and error. Could you please try the following with .NET 4.0 Client + Extended installed on the machine and notify us on the results:

• Reinstall Ranorex 3.0.4 using the EXE file (not the MSI) just to make sure all prerequisites are installed.
• Try to run the "WinForms Test" sample included with the Ranorex setup. If you just have a runtime license, please compile it on your development machine and move the complete output folder to the target machine.
• Try to add an app.config to your test project as explained in "Reason #6" in the Ranorex User Guide:
  http://www.ranorex.com/support/user-gui ... html#c3250

The AUT used in the WinForms test sample is also a .NET 2.0 Window Forms application compiled to target x86; so it is very similar to your AUT regarding its technology. Let's see if automating that sample application succeeds.

Regards,
Alex
Ranorex Team

[Ciege]

Reinstall Ranorex 3.0.4 using the EXE file (not the MSI) just to make sure all prerequisites are installed.

Was already using the EXE not the MSI to install. However, I am using 3.0.2 right now not 3.0.4.

Try to run the "WinForms Test" sample included with the Ranorex setup. If you just have a runtime license, please compile it on your development machine and move the complete output folder to the target machine.

Done, and it seemed to work fine. There were no errors in the log.

[*]Try to add an app.config to your test project as explained in "Reason #6" in the Ranorex User Guide:
http://www.ranorex.com/support/user-gui ... html#c3250

I'm not sure I follow this...
Do I need to recompile my AUT and add an app.config? Not sure I will have access to do this...
And then, I need to move the app.config (after it has been renamed to the AUT's name) into the folder with the Ranorex EXE or the EXE of the compiled automation script?

By the way, I am going to be out of the office 7/28 (tomorrow) - 8/3. So I will not be updating this thread until then unless I have more information today.