Package changes leave (loaded?) dlls unchanged

OpenRPA version:
OpenFlow version: N/A
Using or self hosted openflow: offline
Error message: none
Screenshot or video: n/a

When updating or uninstalling a package, the dlls from extensions folder should be cleaned up/changed to newer versions, but it doesn’t seem to happen.

Looking through the code, they seem to be added to PendingDeletion (here), and should be cleaned up later (I guess after they’re unloaded from domain on restart?), but in practice they stay unchanged.

Repro steps:

  1. Install any package (some older version), f.e. RestSharp
  2. Open the extensions folder and check file details (version etc.)
  3. Update the package to a newer version
  4. Observe that files are unchanged
  5. Restart OpenRPA
  6. Observe that files are still unchanged

Originally this was observed with a custom .nupkg, but it seems to affect all of them. Only workaround is to clean up extensions manually, but that “breaks” as soon as you have more than a couple packages installed (or packages with dependencies etc.).

I agree it’s misleading, but the thinking was this.

  • We cannot unload a dll, and we cannot delete a locked file. So if you uninstall a package, you would also close OpenRPA. And we then add a list of files to be delete, once you start OpenRPA again, before loading plugins and packages.
  • Once restarted, you might install a different or the same package, and this will then add a new set of dlls to the extension folder that we then load, to update the toolbox

This is a design flaw, based on the fact the designer is running in the .exe we launched. UiPath’s idea of running the designer and “robot runners” in a different process is SOOOO much better, precisely for this reason.

there for, you cannot uninstall a package and install a different version of the same package in the same “session”.

i believe there is still ( or least there was at some point ) a message box telling you to restart openrpa, when you uninstall a package.

There’s some output in the logs (didn’t see that before):

[14:32:16.130][Warning] package files will be deleted next time you start the robot
[14:32:16.130][Output] Please restart the robot for the change to take fully effect

Doing the exact steps works:

  1. Open OpenRPA
  2. Uninstall the package
  3. Close OpenRPA
  4. (files get cleaned up)
  5. Open OpenRPA
  6. Install different version

The message does NOT show when you do the “Update” though, only when you uninstall the package.

Interestingly, the Update package works if it has been installed on the same “run” of OpenRPA. But, if you install, close, then reopen and update package to a different version, it’s pretty inconsistent.
It looks like it tries to uninstall first, then install a different version, but the files are locked, so it ends up (for me at least) removing all the dependencies, but leaves the main .dll intact (so the update doesn’t actually change the version).

For now the workaround you mentioned works, but that Update “bug” can lead someone down a rabbit hole of debugging.
Since it’s pretty “inconsistent” (at least from the users perspective it might look like that), I’m not sure if the “Update” shouldn’t just result in a MsgBox(“To install a different version of the package, uninstall it, restart OpenRPA and install the version you need”). That way the user will be directed to the steps that do work every time, instead of just some of the time.

yeah, it’s a mess. It could really use some love.

a “quick” work around could be to disable/remove the update button, and force openrpa to close on uninstall (or prompt for it ?)

I’d go with either a disable with a tooltip, or rewire it to just show a message box with steps to follow.
Forcing a restart is going to get messy, and it doesn’t really help much - since it needs to fully remove the .dll’s before it can install the new version (otherwise name clashes in the extensions folder), then it can’t really do it anyway, unless aside of queueing to delete it would also queue to install, but that’s way above a simple workaround.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.

I have uploaded a new version of OpenRPA where the update buttons has been removed

I’m going through the cases where this might pop-up, and I think there’s one more place → when importing/getting pushed a project update that has a newer dependency version than the one installed.
Not sure how that one can be solved though, as it is by definition happening when OpenRPA is open. For HD Robots that’s manageable by the support teams, but for attended users I don’t see a straightforward way of doing this.
I guess going to the extensions and just cleaning it out, and letting a full restore happen, is one way?

I don’t have a good solution for that.
Until I get started on the next version of OpenRPA or decide to give it a big overhaul and separate designer/runtime from the main program, like UiPath.

One workaround could be to create a PowerShell script that kills OpenRPA, deletes the files, and restarts OpenRPA again. You can create a workflow that creates a file with the content in temp, and then runs it using Start Process. You still need to ensure you don’t have conflicting versions, but running this once a day could ensure everyone is always “on par” ?

There’s different ways of doing that, that’s not the issue.
I was just fishing for a solution that doesn’t involve hard file deletes.

Thank you for the support.

In .NET, once a DLL is loaded, you cannot unload it, and in most cases, the file will also be locked on the file system.
So how to fix:

  1. You can load the DLL in a separate domain and unload it. Either everything that needs the DLL then needs to run in that domain, or you need to use marshalling to call any function in the DLLs. The first would involve rewriting everything; then you might as well use separate processes. The second is not going to work since we are using unsafe references and/or cannot serialize all objects (like the workflow context).
  2. Separate the designer and runner from the main process. This has a billion pros. But the reason I did not do it in the beginning was to increase speed and to avoid creating one more set of interfaces for communication between the “host” and runner/designer. And don’t even get me started on debugging; I’m not sure how that would work (like the object inspector).
  3. “Workarounds” - I could make it a feature of OpenRPA to support restarting itself (check for running workflows, etc.), but that just feels hacky.