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.

Todas las plantillas de proyecto disponibles en Studio incorporan sus propios paquetes de dependencias predeterminadas.

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

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.

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. Para gestionar las dependencias de un proyecto, haz clic 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. Las dependencias predeterminadas se muestran junto con las versiones que están actualmente vinculadas al proyecto. Para actualizar un paquete, haz clic derecho en el icono de actualización , situado junto al número de versión disponible. El icono se muestra junto al paquete, lo que significa que las dependencias están listas para instalar.
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 que falten o no sean válidas están marcadas en el panel Diseñador, mientras que un banner de errores proporciona información adicional sobre el flujo de trabajo y sus conflictos de dependencia no resueltos.

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 tiempo de ejecución 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 tiempo de ejecución 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.

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

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 más antigua y la regla de tiempo de ejecución Estricto. La dependencia de nivel superior utilizada en este caso es v2.0, y aparece 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 más antigua y la regla de tiempo de ejecución Versión aplicable más antigua. La dependencia de nivel superior utilizada en este caso es v2.0, y aparece 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 Estrictas 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: Abrir proyectos creados con 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 pendientes y establece la regla de tiempo de ejecución Estricto para los paquetes que encuentra. Al usar 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.

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

Los proyectos creados con versiones anteriores a v2018.3 que nunca se publicaron no tienen dependencias citadas en el archivo project.json. Al abrir dichos proyectos, una alerta del panel Salida te avisa de las dependencias pendientes. Los paquetes de UiPath^® entregados localmente con Studio se añaden como dependencias con la regla de runtime estricta. Se establece automáticamente la versión más nueva de dichos paquetes.

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 establecer la fuente requerida.

• Usar la herramienta Actualización masiva de las dependencias del proyecto para añadir la dependencia que falta a un lote 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. 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: 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.