23.10 - Bug - Coded automation or coded source file perhaps. not sure

Hi, this is happening in one of my projects. Everything was alright last night but now.
some weird stuff is happening.

I believe is caused by Coded automation or Coded source file. I use both in my project. and never seen this happen to any of my other projects which do not use any coded automation or coded source file.

  • All workflows have changed apperance.

  • Bounch of weird looking expression files in project folder:

The project works, but It’s a hassle having to to open the workflows from project panel. and not being able to see any arguments/mapping them.

I dont believe its related to coded workflows. Its from compiling the code to run it, which happens with both normal and coded workflows. The files you see are the compiled code which get packaged together into a nuget package.
Usually you won’t see them write all these files as they get cleaned up, something appears to be interferring with Studio cleaning up after itself.

1 Like

1/ I also observed such strange visual presentation of activities. It hapenned even before 23.10. Usually restart helped…

2/ As @Jon_Smith wrote: DLLs are product of compilation. You could safely delete it (or backup first if you want to be on safe side).


1 Like

Thanks for your replies guys.

I found a new package was installed under dependcies “system.activities.runtime” it had somehow replaced the regular “system.activities”

I simply deleted it and installed the regular system.activties agian and it fixed the project.

I deleted the temporarily files, thanks for pointing that out @Jon_Smith I feel like my studio lags slightly less now :slight_smile:

Studio indeed will lag less as there are less files to keep track of.

A mistake must have happened during you adding the UiPath System Activities and you instead added the Runtime version.

UiPath have now decided to try to split their packages in two (linked is a topic of me complaining of it).
Its supposed to do something to make bots run faster, I don’t really see how and if so that the speed difference would be worth the hassle.
All I have noticed is now I have twice as many packages to handle and confusions like this happen, completely negating any speed improvements.

I requested some stats on how much it improves performance but alas I havent got any response.

This is configurable. You can still publish libraries as a single package if it makes sense for your need.

The point for this split is to optimize the runtime and to allow robots to start execution faster, with less space needed.

Yeah, I have seen this, but no stats on what kind of difference it makes.
It seems to just cause problems from what I see, so I really want to know what sort of time savings we are making to be worth managing twice as many packages in pipelines and between tenants to accomomodate this.

Btw. Most likely the bug occurred for me when project was running and I tabbed out of the RDP I was on, and the RDP server dropped connection, later when I logged back in and opened the project, the project had the extra runtime package.
But now I know to look for it if it happens :slight_smile: