Administrar Dependencias

Gestiona las dependencias del proyecto en Studio, incluida la adición, actualización y eliminación de paquetes de actividades vinculados a un proyecto de automatización.

Las dependencias del proyecto en Studio se refieren a paquetes vinculados a un proyecto específico. Estos paquetes contienen actividades, ya sean predeterminadas o personalizadas.

Las dependencias son contextuales y representan:

• Actividades que utiliza el proyecto
• Variables del proyecto
• Argumentos de entrada y salida

Una dependencia se establece solo si tiene al menos una referencia en la definición del proyecto.

Dependencias predeterminadas y personalizadas

Las dependencias predeterminadas para un proyecto difieren según el tipo de proyecto, la compatibilidad o la plantilla usada para crearlo.

Si tienes que añadir más, haz clic en el botón Gestionar paquetes e instálalas. Las dependencias instaladas solo están disponibles para el proyecto actual, y la lista de dependencias por proyecto puede verse en el archivo project.json.

The Explorer panel displays the activities packages installed in the automation project, together with their sub dependencies, runtime rules, requested, and resolved versions. The project compatibility is displayed in the Dependencies node.

Mantén el puntero sobre una dependencia para ver las versiones solicitadas y resueltas. Las acciones contextuales como Gestionar, Reparar o Eliminar dependencia solo están disponibles para las dependencias y no para sus subpaquetes.

El estado de las dependencias en el árbol está codificado por color de la siguiente manera:

• Rojo: no se encontró la dependencia.
• Anaranjado: no se encontró un subpaquete.
• Gris: la dependencia no está resuelta.
• Azul desvaído: la versión resuelta es mayor que la versión solicitada.
• Azul intenso: hay una coincidencia exacta entre la versión solicitada y la versión resuelta.

Añadir y actualizar dependencias

Para añadir dependencias a un proyecto, instálalas desde la ventana Gestionar paquetes.Ten en cuenta que los paquetes disponibles difieren en función de la compatibilidad del proyecto.También puedes instalar un paquete añadiendo una de las actividades que contiene a un proyecto de la categoría Disponible del panel de Actividades o la barra de búsqueda Añadir Actividad.

Cada vez que hay versiones nuevas disponibles para las dependencias del proyecto actual, en el botón Gestionar paquetes de la cinta aparece un icono de actualización .

1. To manage dependencies in a project, open the context menu for the Dependencies category in the Explorer panel, and then select Manage. This opens the Manage Packages window, with the Project Dependencies category. The icon shows which packages are currently installed.

   

2. Default dependencies are displayed, together with the versions that are currently linked to the project. To update a package, select the update icon , next to the available version number. The icon is shown next to the package, meaning that dependencies are ready to be installed.

3. Las dependencias se instalan en el proyecto solo después de seleccionar Guardar. Al mismo tiempo, las versiones de las dependencias se actualizan en el archivo project.json perteneciente al proyecto.

Resultado

Las dependencias seleccionadas se añaden o actualizan en el proyecto. Las versiones del paquete se actualizan en el archivo project.json.

Eliminar dependencias

• To remove a project dependency, right-click the dependency in the Explorer panel, and then select Remove Dependency. The dependency is removed from the Explorer panel and project.json file. Alternatively, you can go to Manage Packages > Project Dependencies, select the dependency to remove, and then click Uninstall.
• To remove all unused dependencies in the project, select Remove Unused > Dependencies in the Studio ribbon, or use the Ctrl + Shift + R keyboard shortcut. All the installed packages that have no references in the current project are removed from the Explorer panel and project.json file.

Reparar dependencias

If a workflow opened in Studio has references to packages with versions that aren’t available in current Studio feeds, said dependencies are marked as broken in the Explorer panel and details are made available in the Output panel.

Reparar dependencias

Studio allows for all dependencies to be repaired in bulk or individually. To repair all broken dependencies, right-click on the Dependency node in the Explorer panel, and click on Repair Dependencies.

Haz clic derecho en una dependencia dañada y selecciona Resolver dependencia para repararla de forma individual. También puedes seleccionar Gestionar para abrir la ventana Gestionar paquetes y actualizar los paquetes.

NuGet resuelve las dependencias dañadas aplicando la regla de tiempo de ejecución Versión más antigua aplicable , lo que significa que busca la primera versión del paquete aplicable posterior a la instalada anteriormente.

Nota:

Las actividades pendientes o inválidas se marcan en el panel Diseñador, mientras que un anuncio de error proporciona información adicional sobre el flujo de trabajo y sus conflictos de dependencias sin resolver.

Configurar reglas de dependencias

Los paquetes de actividades están disponibles en múltiples versiones, razón por la que tras instalarlos o actualizarlos usando la opción Gestionar paquetes, puedes configurar reglas de tiempo de ejecución de dependencias para cada una de ellas.

La Regla de tiempo de ejecución especifica qué versión del paquete hay que instalar en el tiempo de ejecución. Cuenta con dos opciones.

The Strict runtime rule is the default state for dependencies added upon process creation, and for activities packages installed from the Manage Packages window. It means that only the specified version of the package is used at runtime to execute the parent process. The Strict rule is marked in the Explorer panel, under Dependencies by the sign next to the package version.

The Lowest Applicable Version runtime rule means that if the target package isn’t found, the next higher version is searched in order to resolve dependencies. The Lowest Applicable Version rule is marked in the Explorer panel, under Dependencies by the sign next to the package version.

Ejecutar con reglas de dependencia

Al ejecutar un proyecto de automatización desde Studio, el Robot descarga la versión del paquete especificada o indicada que necesita para ejecutar el proyecto de acuerdo con las reglas de tiempo de ejecución establecidas previamente para cada paquete. Si la dependencia utilizada durante la ejecución tiene una regla de tiempo de ejecución Estricto y no se encuentra la versión del paquete exacta, aparece un error. Para obtener más información sobre el establecimiento de reglas de tiempo de ejecución para dependencias de proyectos, consulta la página Gestionar dependencias.

Resolver conflictos de dependencias

La instalación de paquetes de actividades tiene en cuenta las reglas de runtime de dependencia establecidas previamente. Sin embargo, pueden producirse conflictos entre versiones al automatizar proyectos.

Tanto el proyecto de automatización como sus bibliotecas pueden contener el mismo paquete de actividades con diferentes versiones y reglas de runtime. En tiempo de diseño, NuGet resuelve tales conflictos eligiendo la dependencia de nivel superior: la más cercana al proyecto en la jerarquía.

A continuación se explica cómo resolver los conflictos que podrían generarse:

El proyecto contiene un paquete de actividades con la versión 1.0. La biblioteca hace referencia al proyecto y utiliza el mismo paquete, pero con una versión posterior. La dependencia de nivel superior v1.0 se usa en el tiempo de ejecución. Aparece un aviso que indica que se detectó un cambio a una versión anterior.

La resolución de este escenario es aplicable con independencia de la regla de tiempo de ejecución (Estricto o Versión más antigua aplicable ) establecida previamente para los paquetes de actividades.

• Si eliges Sí, el paquete de actividades referenciado en el proyecto se actualiza a la versión utilizada en la biblioteca.

• Si eliges la opción No, se abre la ventana Gestionar paquetes con la ventana Dependencias del proyecto.

  

El proyecto contiene un paquete de actividades con la versión 2.0. La biblioteca utiliza el mismo paquete, pero con una versión inferior y el estricto regla de tiempo de ejecución. La dependencia de nivel superior utilizada en este caso es v2.0 y se da una advertencia cuando el paquete se instala en el proyecto.

El proyecto contiene un paquete de actividades con la versión 2.0. La biblioteca utiliza el mismo paquete, pero con una versión inferior y la versión aplicable más baja regla de tiempo de ejecución. La dependencia de nivel superior utilizada en este caso es v2.0 y se da una advertencia cuando el paquete se instala en el proyecto.

El proyecto hace referencia a una biblioteca con una versión del paquete de actividades 1.0 y la regla de tiempo de ejecución Estricto . El proyecto hace referencia a otra biblioteca, pero con una versión del paquete de actividades 2.0. La dependencia de nivel superior en este caso es el paquete con v2.0, puesto que tiene la versión más nueva. Cuando el paquete de actividades se instala, aparece una advertencia.

En este conflicto, el proyecto hace referencia a dos bibliotecas que, a su vez, tienen dependencias Estricto referenciadas entre ellas. Este escenario no se admite. Para obtener información detallada, consulta la página Resolución de dependencias.

Los ciclos de dependencias son tipos de conflictos que se generan cuando un paquete hace referencia a sí mismo. Si llamas a tu proyecto UiPath, Studio detecta un conflicto de dependencias. Esto ocurre porque el paquete UiPath ya existe y es una dependencia para UiPath.UIAutomation.Activities. Se recomienda evitar asignar al proyecto el nombre de un paquete ya existente que intentas añadir como una dependencia.

El mismo ciclo de dependencias se produce si abres un archivo .xaml desde una carpeta llamada UiPath o cualquier nombre de un paquete ya existente que intentas añadir como una dependencia y no hay project.json en esa carpeta. Cuando abres un archivo .xaml que no tiene un archivo project.json asociado, Studio crea uno y la etiqueta "name" se rellena con el nombre de la carpeta principal.

Abrir proyectos creados con versiones anteriores

Importante:

No es posible abrir proyectos creados con la versión de Studio v2016.2 directamente en la versión v2020.4 o superior. Primero abre estos proyectos con la versión v2018.4 de Studio y luego con la 2020.4 o superior.

Al abrir un proyecto con o sin dependencias, diseñado con una versión anterior a v2018.3 (excepto para v2016.2). Studio te pregunta si se realizará una migración automática, para tratar de recuperar las dependencias que faltan o añadir las predeterminadas.

Upon confirmation, Studio attempts to retrieve missing dependencies and sets the Strict runtime rule for the packages that it finds. When using the Repair Dependency option in the Explorer panel, Studio attempts to install the next best package version. If the package version is not found, alerts are shown in the Output panel and you should check the configured feeds in the Manage Packages window.

Dependencias para proyectos antiguos

Los procesos que contienen dependencias y que se crearon con versiones de Studio anteriores a v2018.3 siguen ejecutándose con Robot v2018.3. La regla de runtime para dichos proyectos se establece en Versión más antigua aplicable.

Los proyectos creados con versiones anteriores a v2018.3 que nunca se publicaron no tienen dependencias enumeradas en el archivo project.json . Al abrir dichos proyectos, una alerta en el panel Salida te notifica las dependencias que faltan. Los paquetes de UiPath entregados localmente con Studio se añaden como dependencias con el estricto regla de tiempo de ejecución. La última versión de dichos paquetes se establece automáticamente.

Si dichos proyectos contienen paquetes distintos a los entregados con Studio de forma local, recomendamos:

• Publicar el proyecto utilizando la versión de Studio en la que se creó, lo que ayuda al proceso de migración al añadir dependencias en el archivo project.json;
• Instalar manualmente el paquete que falta desde la ventana Gestionar paquetes, después de configurar la fuente necesaria;
• Usar la herramienta Actualización masiva de dependencias del proyecto para añadir la dependencia que falta a un volumen de proyectos.
  Nota:

  Los flujos de trabajo que contienen actividades inválidas no se pueden guardar. Instala la dependencia necesaria y, a continuación, guarda el proyecto.

Los paquetes de actividades UiPath.V7.Activities, UiPath.Platform.Activities y UiPath.Framework.Activities están obsoletos. Al abrir proyectos con paquetes UiPath.Platform.Activities y UiPath.Framework.Activities, la versión de Studio v.2018.3 o posterior intenta realizar una migración automática para reemplazar las versiones antiguas de actividades por unas nuevas.

Nota:

Los flujos de trabajo que contienen actividades que forman parte del paquete UiPath.V7.Activities no pueden migrarse.

Existe una solución para casos en los que la migración no se realiza de forma automática.

1. Abre el archivo project.json con Notepad++.
2. Elimina el parámetro "schemaVersion": "3.2".
3. Sustituye "studioVersion" por "toolVersion".
4. Cambia el valor "toolVersion" de "18.3.xxx" a una versión anterior. Por ejemplo, cambia el valor de "18.3.0.958" a "18.2.958". Guarda el archivo.
5. Open the .xaml file with Studio v2018.3 or above for the migration to be performed. The deprecated activities packages are replaced with new ones, as illustrated in the Dependencies section of the Explorer panel.
   Nota:

   En algunos casos, los archivos .xaml que contienen los paquetes UiPath.Platform.Activities y UiPath.Framework.Activities no se pueden migrar de forma automática y la solución no es aplicable. En estas situaciones, se recomienda abrir el proyecto en Studio v.2018.2 o anterior y sustituir las actividades pertenecientes a los paquetes mencionados por actividades contenidas en el paquete UiPath.Core.Activities. Se puede hacer lo mismo para los flujos de trabajo que contienen actividades del paquete UiPath.V7.Activities.

A partir de Studio v2018.4.1, Microsoft.Activities v.1.0.1 y Microsoft.Activities.Extensions v2.0.6.9 ya no están empaquetadas en el instalador UiPathStudio.msi.

En caso de que sea necesario reparar al migrar proyectos que contienen estos paquetes como dependencias, instala los dos paquetes desde la fuente Oficial o la fuente local. Antes de ejecutar dichos proyectos creados con versiones anteriores a v2018.4.1, comprueba que los paquetes mencionados estén disponibles en una fuente a la que el Robot pueda acceder.

Si te actualizas desde una versión anterior a v2018.4.1, los dos paquetes de actividades permanecen en la fuente Local.