This post is currently in a preview version and will be further updated in the near future.
In the context of preparing for a legacy-to-Windows migration, it may be necessary to check which compatibilities are offered by a package (NuGet Package). This part of the [InfoSet] -LegacyToWindows Migration series presents various options for such an evaluation.
Artifacts referenced in the source code projects / UiPath Studio projects are provided by NuGet packages. A package can offer the provided functionalities for one or also different target platforms. For the Legacy-To-Windows migration it is therefore important whether the package is compatible with the target platform targeted in the migration (Windows) or not.
The Microsoft Code Platform defines products (target frameworks) that are available in different versions. This information can be used to check the availability of a NuGet package for the compatibility of a UiPath Studio project.
|.Net Framework||net4##||Legacy||# - Digit ~ marking other Framework Versions|
Some of the options listed below refer to the overview above when it comes to analyzing information about a NuGet package more deeply
Many NuGet packages provide a link to the associated project website in their metadata. The available compatibility can be found in the documentation/developer references.
UiPath documentation pages for activities or packages often mention the compatibility offered.
Packages are generally offered via feeds. Further information on this can also be found there and clarify the question of available compatibility.
A note on the UiPath Marketplace
It may happen that not all supported compatibilities are displayed. For example, a custom library may be compatible with Legacy and Windows. However, only one compatibility is mentioned on the overview page.
But the custom library is compatible with Legacy and Windows, which was also explicitly noted by the author.
Once a UiPath Studio project is open and the project has set the corresponding target platform in its compatibility, the availability of a package can be checked via the Package Manager (Ribbon menu item: Manage Packages). Only packages that are available for the compatibility set in the project are offered.
In case of restricted internet access (e.g. firewall rules), the providing nuget feed may be blocked. Such a situation should not be misinterpreted and falsify the evaluation of the compatibility.
When testing with this method, make sure that all other packages required in the project are also referenced with the appropriate version.
The configured global-packages folder is used for unpacking NuGet packages. By default this can be found under
Whenever a nuget package is already available in the nuget repository the expanded package content can be checked.
perform the following steps
- use the File Explorer and navigate to: %userprofile%.nuget\packages
- locate the folder of the corresponding package name (in most cases the same name as the package ID)
- open the folder with the relevant package version info
- open the lib folder
- take the hint from the subfolders name
Create a copy of the package and perform the following steps
- rename the file extenssion to zip
- expand the resulting zip archive locally
- inspect the subfolder names from the lib folder
The dependencies defined by the package can be read from the package metadata. The following options can be used to inspect the metadata.
Assuming that NuGet Package Explorer is installed, perform the following steps:
- Open the package to be examined in the NuGet Package Explorer
- The dependencies are noted at the bottom left of the page.
- Check which dependencies to .Net are defined
- If only .NETFramework4.X/.NETFramework4.X.Y is referenced, then the package is not Windows compatible.
It may be the case that no indications of compatibility can be taken from the metadata. In such a case, the package content can be inspected within the Nuget Package Explorer. Similar to the description under File System - nuget Repository folder, the LIB folder can be opened and the names of the subfolders can be further inspected.
Example of a Package defining compatibility for Legacy and Windows
Formally, it is mentioned that there are other ways to check a NuGet package for UiPath Studio project compatibility besides the ones presented here. If it becomes known from the various migration projects that another option is also used particularly frequently, it will be added to the list.
A package can be quickly checked for compatibility if the subfolders of the LIB folder from the package content are evaluated. The availability of the package plays a role in the selection of the method for the evaluation. Already installed packages can be inspected in the global-packages folder. Locally available packages are extracted manually or opened with the NuGet Package Explorer.
Once a UiPath Studio project is currently open and package dependencies are configured similarly, then a test can be carried out via the Package Manager. However, it should be ensured that package feeds are also accessible.
If a local download of packages is not desired, the websites of the project or of feeds that offer the package are a good first starting point.
For questions on your specific case or migration topic open a new topic and get individual support.