Object Descriptor unable to see application Window

Help Studio
1

Hi, looking for some guidance on a solution to arather odd issue I have never seen before in UiPath Studio.

In only specific library for a specific old windows app, we;ll call it ‘MIS’ following a re-clone of the library project via Git yesterday afternoon, all of the Ui objects are not working as they cannot see that the application is open. I’m presented instead with the off-line version of the descriptor editor.

I am able to create new objects - screen and element - in the same MIS app, with the same window and target selectors - and they always work, always see the app.

When editing a ‘faulty’ ui object for the MIS app I am able to point it at the open application, if then sees the app ok. I can edit the window selector ok and validate it and then save it. I then re-open the ui object via edit descriptor and it no longer finds the MIS application window.

We’re now seeing this on the remote VMs, as of this morning, executing test cases where that use the activities in the the MIS application library. The first activity to open the application is failing on a wait (check app state) for the application window.

Here’s the odd thing:

  1. UiExplorer has no problems seeing the app and can validate the same window selector used in the Ui objects (the window selectors are all the same for the same app)!
  2. It is only one library project where this is happening. We have two other libraries - one for Citrix Workspace and another for MS apps, and they are ok.
  3. My colleague using the same library project had no problem - at least until today.

We are coming to the conclusion that either:
(a) something has changed on the desktop environment that is corrupting the ability for UiPath to use the UI objects, or more specifically ui objects from one specific library (though this surely would affect all libraires and also Ui Explorer?)
(b) the library project descriptors have somehow been corrupted.

A solution appears to be that we could re-create all ui objects, even in a whole new project. It may even work to copy the entire UI object tree via snippets between and old and new project.

If anyone has experienced this and either:
(a) knows what might have caused this - library project corruption, desktop environment change
(b) has a fix for the errant library project
(c) any other solution to re-creating the entire project (assuming this will work) or else re-create all the Ui objects

We’re using:
UiPath Studio 24.10.18 LTS on Windows 10.
UiPath.System 24.10.8
UiPath.UIAutomation 24.10.14

Many thanks
Steve

2

Hi @stevewakley ,
You can try with these below steps:

  1. Refresh or recreate the affected UI Objects and save them again.
  2. Clear the local project cache (.project/.local) and reopen the solution.
  3. Compare the faulty UI Object descriptors with newly created working objects.
  4. Reinstall or update the UIAutomation package to the latest compatible version.
  5. If only this library is affected, create a new library project and migrate the workflows/UI Objects into it.
  6. Re-publish the library and update the dependent test projects.
    If these steps doesn’t work please let me know.
3

Hi Jasmine,

Thanks.

By way of update, it appears that it’s the current Bitbucket repo for the library project that has been corrupted (though as yet we have no explanation of what, how or why).

I opened a previous archive copy (I create one just about daily) and found one last week where the Ui objects were ok. My colleague is working on his local copy of the project where this issue doesn’t occur, so looking like we can archive the old repo and push his project into a new repo.

I did try creating a whole new library project and, via snippets, copy the corrupted UI objects into it and this didn’t solve the problem - the objects still didn’t work - and I was still able to create new objects with the exactly the same selectors that do work. I suspect than the local project cache is not the issue, but properties of the files for each ui objects themselves.

We’ve been continually having issues with pushing and pulling changes from the Bitbucket repo in UiPath, since we both started working on the same project. We now regularly need to re-clone the project, copy in changed workflows from the pervious local copy and then push changes. Even opening a project we just updated into the repo, making a small change fails to push.

We suspect this might be the cause of the corruption of the Ui objects and the company needs to migrate to the latest version of Studio, or do all the GIT work manually in GitBash.

4

Hi @stevewakley

since you said a new descriptor with the exact same selector works but the old one doesnt, the difference has to be inside the descriptor file itself, so maybe worth opening the .objects folder of the project in a text editor and comparing a broken one against a working one side by side

if the repo mangled them you should see it there, and a git diff on that folder between your working archive copy and the current repo would show exactly what changed. My guess is the descriptor lost its reference to the parent application/screen node, wich would explain the “unable to see application” part specifically

also worth checking if your repo has a .gitattributes and what your autocrlf setting is, line ending normalization on those files can break them silently, and that would fit your case since it only started when two people began pushing to the same project

hope this also helps to complement the investigation

5

Hi Michael,

Thanks. It’s certainly worth investigating further once we’ve got a repo copy of the project that works - assuming this isn’t all something to do with my local Studio instance?

Update: I tried opening a copy of my colleagues’s local project and in my Studio instance the same Ui objects don’t work yet work fine on my colleagues PC.

This implies it’s my local Studio instance or desktop configuration that is the problem. The only solution I can think of is getting Studio de-installed, clean out any local library cache folders, etc and then re-install Studio.

Any other options appreciated

6

Hi @stevewakley

good test. Before going for a full reinstall, maybe worth comparing the resolved package version between the two machines. Open Manage Packages on the same project on your PC and on your colleagues and check what version of UiPath.UiAutomation.Activities is actually resolved, not what the project asks for. If your local cache served a different build, the descriptors could be read with a different schema and that would explain old ones failing while new ones you create work fine

if they differ, clearing the local nuget cache is much lighter than reinstalling, the folders are under %userprofile%.nuget\packages and the UiPath ones under %localappdata%\UiPath. Delete the uiautomation ones, reopen the project and let it restore

also worth a look at your package sources in Studio settings, if you have an internal feed that your colleague doesnt, you might be pulling a different build from there without noticing

hope this saves you the reinstall

7

Hi Michael, that was kinda where I was headed too, though I didn’t appreciate that there could be differences in the resolved UiAutomation activities package. I’ll let you know how I get on.

8

Hi again Michael,

Checked this morning, it’s asking for and resolving to the correct version of UiAutomation activities library. I’ll now try clearing local cached UiPath .nuget packages…

This has not fixed the issue, UiPath still thinks the Window selector is invalid as cannot see the app as reported at the top of this.

If anyone else has any suggestions, before I ask for a re-install of Studio, that would be welcome (I’ve avoided this so far as it could mean I don’t have Studio for a day or 2 due to local IT support enagement processes)

@UiPath_Community
@UiPathMaster