UiPath offers the possibility to use individual assemblies, also known as process libraries in form of packages, in the context of the automation workflows. This gives us a high grade of flexibility of the reuse of consolidated functions that are provided as a library. On the other hand the use of too many libraries also contains risks, e.g. the ambiguity of class names which then lead to an error, as can be seen in this example. Recently, I faced exactly this problem and had to solve it. In this post I describe a way to efficiently detect such kind of errors.
To detect ambiguous names I use a tool called ILSpy, an open-source .NET assembly browser and decompiler. It is distributed under the MIT License, so you can use it in commercial environments.
To get all libraries open the path
C:\Users\YourName\.nuget\packages in the Windows Explorer. Type in the search bar
*.dll NOT *resources* to find all assemblies.
Open the intermediate language spy and drag and drop all assembly names from the Windows Explorer to the ILSpy.
Now you have to wait a little bit.
After you have drunk your coffee open the search window.
Enter the name of the method or property that is named in the error message.
A short time later you will receive a search result.
Depending on the dotNET framework, it is now possible to detect very quickly which library is causing the error. Now you can replace the library with an other version from the NuGet Gallery.
For stable operation is this kind of an analysis necessary in advance when using new libraries. Otherwise this anomaly may only become apparent during development, or worse, during production. This way saves a lot of time in finding this kind of errors.