.xaml, or something related to Source Control / Cloud sync reverting the file?
Its most likely because the code has been pulled out of a nuget package, you shouldnt be doing that.
The tell tale sign in the Runtime dependencies, which causes this.
Unless you had something very weird happen during a publish its almost certainly this, just stop doing that.
Hello @Ravi_Gandroli,
I think this is a save issue.
I have "itext": "[9.7.0]" in my project.json, added yesterday for PNG-to-PDF merging. That’s a raw NuGet PDF library, not a proper UiPath activity package. I’m guessing this created a dependency/type resolution conflict with UiPath.System.Activities.Runtime (which Retry Scope depends on) during publish, causing it to render empty on reopen. Would the fix here be to remove the raw iText reference and instead use UiPath.PDF.Activities or UiPath.Document.Processing.Activities for the merge, or is there a way to safely keep iText without this side effect?
Hi @Ravi_Gandroli ,
I think the .xaml file was not saved correctly, became partially corrupted, or was overwritten by Source Control/Cloud sync.
.xaml with the last committed version..xaml in a text editor and search for RetryScope to see if the condition and body activities still exist in the XML.Thanks
hey @Ravi_Gandroli ,
Remove the raw itext reference from your project.json. UiPath.PDF.Activities already ships its own iText build internally, so pulling in 9.7.0 separately gives you two copies of the same assembly, and the resolver picks the wrong one at design time. That’s why Retry Scope renders empty — Studio can’t resolve the container’s designer types, so it draws a blank body instead of erroring out.
Use UiPath.PDF.Activities (Join PDF Files / Image to PDF) or UiPath.DocumentProcessing.Contracts activities for the merge instead. If you really need something only iText can do, wrap it in a custom activity package with its own dependency graph and reference that .nupkg — never the raw library inside a process project.
After removing it:
.local folder%userprofile%\.nuget\packagesYour .xaml is almost certainly fine — open it in Notepad++ and search for RetryScope, you’ll see the condition and body still sitting there.
No. Its not related to that in my opinion.
Its related to publishing your package, then going into that nuget package and extracting the code from it, and using that for your project.
When you publish your project, the nuget file you generate which goes to the Orchestrator turns some dependencies into runtime ones, and thats your problem.
I have never heard of adding a new package like that corrupting the other packages like that. Its far far more likely someone messed around extracting the code from the nuget like I said.
The other advice here is flat out wrong, and I suspect from an LLM.
The issue is simply the runtime dependencies, you can solve it by converting them to the normal ones, but I am urging you to address the root cause and to stop them becoming runtime ones by doing bad practices.
@Ravi_Gandroli
Whenever you do the modelling in UiPath Studion ensure that you reference the packages and not the related runtime packages:
