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.

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. Las dependencias no resueltas se marcan en gris en el árbol, las dependencias no encontradas se marcan en rojo y las dependencias resueltas y con coincidencia exacta se marcan en azul difuminado y oscuro.

Añadir y actualizar dependencias

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.

To add dependencies to a project, simply search and install them as you would any activity package. For more information, check the Manage Packages page.

Eliminar dependencias

1. Para eliminar una dependencia de un proyecto, haz clic derecho en la dependencia en el panel Proyecto.
2. Selecciona Eliminar dependencia; la dependencia se elimina del panel Proyecto y del archivo project.json.

De forma alternativa, esto se puede lograr haciendo clic en el botón Desinstalar disponible para cada dependencia en la categoría Gestionar paquetes > Dependencias del proyecto.

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.

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 directamente proyectos creados con la versión de Studio v2016.2 en la versión v2020.4. Primero, abre estos proyectos con Studio v2018.4 y después con v2020.4.

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

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 .

Projects created with versions prior to v2018.3 that were never published don't have dependencies listed in the project.json file. When opening such projects, an alert in the Output panel notifies you of missing dependencies. UiPath packages delivered locally with Studio are added as dependencies with the Strict runtime rule. The latest version of such packages is automatically set.

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.