Broken Repository Paths after changing project framework

Ask general questions here.
Posts: 2
Joined: Wed Aug 19, 2020 1:30 pm

Broken Repository Paths after changing project framework

Post by Nofal » Wed Aug 19, 2020 2:03 pm


We previously had recordings on Ranorex for a .Net Standard framework application. Then we have changed the application's framework to .NET Core 3.1. As a result, a lot of Ranorex repository paths broke. We tried to fix them manually using the Spy tool but it is not functioning as we expect. The paths that the Spy tool generate are sometimes generic and inaccurate. Sometimes the Spy cannot find the element, but the recording can.

For example, we also had an incident where the Spy tool would give us a different path for the same element after we run the recording for the first time. The Spy tool would give us a path "//container/combobox", but after we run the recording for the first time and we try to use the Spy tool again for the same element, it gives us the path "/combobox".

Can you please help us solve this problem? Is the .net core 3.1 framework supported?

Below are further details about our environment and plugin settings:
Ranorex Version: 9.3.2
.NET Runtime Version: 4.0.30319.42000

Annotation 2020-08-19 145620.png
Annotation 2020-08-19 145620.png (17.79 KiB) Viewed 365 times

User avatar
Ranorex Guru
Ranorex Guru
Posts: 6360
Joined: Mon Aug 13, 2012 9:54 am
Location: Zilina, Slovakia

Re: Broken Repository Paths after changing project framework

Post by odklizec » Mon Aug 31, 2020 11:04 am


I'm afraid, that xpath differences, in case of updated UI technology, are quite normal and you will have to live with this behavior ;) The only thing you can do about this is to update the affected xpaths and make them somewhat more change-resistant.

Unfortunately, it's hard to suggest something concrete without seeing the repository and a snapshot (not screenshot) of the app under test, taken both with old UI and new one. From your description it looks as if new UI simply eliminated one container? So you must eliminate it from the xpath as well. To prevent the xpath to fail in case of re-adding the container back in future, you can change the xpath like this:

Code: Select all

or like this:

Code: Select all

If you can, please post a Ranorex snapshot of the app under test (taken both with old and new UI) and some examples of failing xpaths. Thanks.
Pavel Kudrys
Ranorex explorer at Descartes Systems

Please add these details to your questions:
  • Ranorex Snapshot. Learn how to create one >here<
  • Ranorex xPath of problematic element(s)
  • Ranorex version
  • OS version
  • HW configuration

Posts: 2
Joined: Wed Aug 19, 2020 1:30 pm

Re: Broken Repository Paths after changing project framework

Post by Nofal » Tue Sep 01, 2020 11:05 am

Hi odklizec,

Thank you for your answer. Yes, receiving different XPath between .net core and .net framework is reasonable for us and we accept this part and have decided to change our current existing element XPath with a new one.

Our Issue

But the issue we are facing is that after switching to .net core the XPath between the two-run isn't sustainable and usually is completely different in multiple runs and each time it detects a completely different path. If I've understood correctly this issue happens when the Ranrorex process still remains attached to our application. In this case, we face this notification from Ranorex: "UI elements in your 'WPF.Core' AUT can’t be identified because it couldn’t be instrumented automatically. Restart all Ranorex tools and the AUT with the same privileges, preferably as an administrator."

What We Tried

We did all steps advised by Ranorex in "General Troubleshooting" for .net core and run both with admin permission and the same CPU type. In the first-run, it seems that everything works well and we don't receive the above message but for the next run, Ranorex has a problem to connect our application, so it gives us a new XPath.


I've attached one snapshot for .net framework and two core XPath. My inspected target element is "ComboBoxOptimizeLevel". In the Second run, Ranorex ignores all parents and couldn’t detect them. We can’t exit our application and need to kill the process because our application cause is still engaged with the Ranorex process.
(66.91 KiB) Downloaded 12 times
(247.53 KiB) Downloaded 12 times
(146.57 KiB) Downloaded 12 times