Administrar Dependencias

Las dependencias del proyecto en Studio se refieren a los paquetes vinculados a un proyecto específico que contienen actividades, ya sean predeterminadas o personalizadas. Las dependencias son contextuales y tienen en cuenta la definición de cada proyecto, incluyendo las actividades que usas, variables, argumentos de entrada y de salida. Por tanto, la dependencia se establece solo si tiene al menos una referencia en la definición del proyecto.

En Studio, las dependencias predeterminadas de un proyecto difieren en función del tipo de proyecto, la compatibilidad o la plantilla utilizada para crear el proyecto.

En StudioX, todos los proyectos incorporan los siguientes paquetes predeterminados: UiPath.System.Activities, UiPath.ComplexScenarios.Activities, UiPath.Excel.Activities, UiPath.Mail.Activities, UiPath.Presentations.Activities, UiPath.UIAutomation.Activities y UiPath.Word.Activities.

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.

El panel Proyecto muestra los paquetes de actividades que están instalados en el proyecto de automatización, junto con sus subdependencias, sus reglas de tiempo de ejecución y sus versiones solicitadas y resueltas. La compatibilidad del proyecto se muestra en el nodo Dependencias.

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

To add dependencies to a project, install them from the Manage Packages window. Please note that the available packages differ based on the project compatibility.

Whenever new versions are available for the current project dependencies, the Manage Packages button from the ribbon gets an update icon .

1. Para gestionar las dependencias de un proyecto, haz clic con el botón derecho en la categoría Dependencias del panel Proyecto y, a continuación, haz clic en Gestionar. De este modo se abre la ventana Gestionar paquetes con la categoría Dependencias del proyecto. El icono muestra los paquetes que están instalados actualmente.

   

2. Default dependencies are displayed, together with the versions that are currently linked to the project. To update a package, simply click on 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 hacer clic en Guardar. De forma simultánea, las versiones de las dependencias se actualizan en el archivo project.json perteneciente al proyecto.

Eliminar dependencias

• Para eliminar una dependencia del proyecto, haz clic derecho en el panel del Proyecto, y luego selecciona Eliminar dependencia. La dependencia se eliminará del panel del Proyecto y del archivo project.json.

  También puedes ir a Administrar paquetes > Dependencias del proyecto, seleccionar la dependencia que quieras eliminar y luego hacer clic en Desinstalar.

• Para eliminar todas las dependencias no utilizadas en el proyecto, selecciona Eliminar no utilizadas > Dependencias en la cinta de Studio, o usa el atajo Ctrl + Shift + R. Todos los paquetes instalados que no tienen referencias en el proyecto actual se eliminan del panel del Proyecto y del archivo project.json.

Reparar dependencias

Si un flujo de trabajo abierto en Studio tiene referencias a paquetes con versiones que no están disponibles en las fuentes de Studio actuales, dichas dependencias se marcan como dañadas en el panel Proyecto y los detalles se ofrecen en el panel Salida.

Studio permite reparar todas las dependencias en bloque o de forma individual. Para reparar todas las dependencias dañadas, haz clic derecho en el nodo Dependencia del panel Proyecto, y haz clic en Reparar dependencias.

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.

Si no se puede encontrar la versión de destino, la función de reparación utiliza automáticamente la siguiente versión superior disponible. Ten en cuenta que este comportamiento depende de la configuración de la fuente.

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.

La regla de runtime Estricto es el estado predeterminado para las dependencias añadidas tras la creación de procesos y para los paquetes de actividades instalados desde la ventana Gestionar paquetes. Esto significa que solo la versión especificada del paquete se usa en el tiempo de ejecución para ejecutar el proceso principal. La regla Estricto está marcada en el panel Proyecto, en Dependencias, con el signo junto a la versión del paquete.

La regla de runtime Versión más antigua aplicable significa que si no se encuentra el paquete de destino, se busca la siguiente versión posterior para resolver las dependencias. La regla Versión más antigua aplicable está marcada en el panel Proyecto, en Dependencias, con el signo junto a la versión del paquete.

When executing an automation project from Studio, the Robot downloads the specified or indicated package version it needs to execute the project, in accordance to the previously set runtime rules for each project. If the dependency used during execution has a Strict runtime rule and the exact package version was not found, an error is thrown. For more information on setting runtime rules for project dependencies check the Managing Dependencies page.

Resolver conflictos de dependencias

La instalación de paquetes de actividades tiene en cuenta las reglas de tiempo de ejecución de las dependencias configuradas previamente para esos paquetes, pero podrían generarse algunos conflictos entre versiones al automatizar los proyectos. Tanto el proyecto de automatización como la biblioteca que contiene podrían tener el mismo paquete de actividades, pero con versiones y reglas de tiempo de ejecución diferentes. En el momento del diseño, NuGet resuelve estos conflictos eligiendo la dependencia de nivel superior, que es 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.

The resolution of this scenario is applicable regardless of the runtime rule (Strict or Lowest Applicable Version ) previously set for the activities packages.

• 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.

Tras la confirmación, Studio intenta recuperar las dependencias que faltan y establece el estricto regla de runtime para los paquetes que encuentra. Al utilizar la opción Reparar dependencia en el panel Proyecto , Studio intenta instalar la siguiente mejor versión del paquete. Si no se encuentra la versión del paquete, se muestran alertas en el panel Salida y debes comprobar las fuentes configuradas en la ventana Gestionar paquetes .

Processes containing dependencies and that were built with Studio versions prior to v2018.3 continue to execute with Robot v2018.3. The runtime rule for such projects is set to Lowest Applicable Version .

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;

• Manually installing the missing package from the Manage Packages window, after setting up the required feed;

• Using the Project Dependencies Mass Update tool to add the missing dependency to a bulk of projects.

  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. Abre el archivo .xaml con la versión de Studio v2018.3 o posterior para que se realice la migración. Los paquetes de actividades obsoletos se sustituyen por otros nuevos, tal y como se ilustra en la sección Dependencias del panel Proyecto.

   Nota:

   In some cases, .xaml files containing the packages UiPath.Platform.Activities and UiPath.Framework.Activitiescannot be automatically migrated and the workaround isn't applicable. For these situations, it is recommended to open the projects in Studio v2018.2 or lower, and replace the activities belonging to the aforementioned packages with activities contained in the UiPath.Core.Activities package. The same can be done for workflows containing activities from UiPath.V7.Activities package.

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.