- Notas de Versão
- Introdução
- Configuração e Instalação
- Projetos de automação
- Sobre a publicação de projetos de automação
- Projetando automações
- Gerenciamento de pacotes de atividades
- Como definir as configurações do projeto de atividades
- Como assinar pacotes
- Governança
- Como importar entidades
- Experiência de Criação Moderna
- Vincular um projeto a uma ideia no Automation Hub
- Usando o Gerenciador de dados
- Dependências
- Sobre dependências
- Como gerenciar dependências
- Atividades ausentes ou inválidas
- Tipos de fluxos de trabalho
- Comparação de arquivos
- Melhores Práticas de Automação
- Integração de controle de origem
- Depuração
- Analisador de Fluxo de Trabalho
- Sobre o Analisador de Fluxo de Trabalho
- STN MG-001 - Convenção de nomenclatura de variáveis
- STN MG-002 - Convenção de nomenclatura de argumentos
- STN MG-004 - Duplicação de Nome de Exibição
- STN MG-005 - Variável substitui variável
- STN MG-006 - Variável substitui argumento
- STN MG-008 - Comprimento de variável excedido
- STN MG-009 - Variáveis Catablema de prefixo
- STN MG-011 - Argumentos Catablema de prefixo
- STN MG-012 - Valores padrão de argumentos
- STN MG-016 - Comprimento do argumento excedido
- SR-DB-002 - Contagem alta de argumentos
- SR-DB-003 - Esvaziar bloco catechu
- SR-DB-007 - Múltiplas camadas Com fluxograma
- SR-DB-020 - Propriedades de saída indefinidas
- SR-DB-023 - Fluxo de trabalho vazio
- SR-DB-024 - Verificação da atividade Persistente
- SR-DB-025 - Pré-requisito de serialidade de variáveis
- SR-DB-026 - Uso da atividade Dela
- SR-DB-027 - Melhores práticas de persistência
- SR-DB-028 - Pré-requisito de serialidade de argumentos
- SR-US-005 - Argumentos de atividades embutidos em código
- SR-US-009 - Variáveis não utilizadas
- SR-US-010 - Dependências não utilizadas
- SR-US-014 - Restrições de pacotes
- SR-US-020 - Mensagens de logue mínimas
- SR-US-024 - Não utilizado e postergado
- SR-US-025 - Uso incorreto do valor salvo
- SR-US-026 - Restrições da atividade
- SR-US-027 - Pacotes necessários
- ST-USG-28 — restringir modelos de invocação de arquivos
- ST-USG-032 — rótulos obrigatórios
- ST-USG-034 — URL do Automation Hub
- Variáveis
- Argumentos
- Namespaces Importados
- Automação assistida baseada em gatilho
- Gravação
- Elementos de Interface Gráfica
- Fluxo de controle
- Seletores
- Repo. de Objetos
- Extração de Dados
- Automação de imagem e texto
- Automação de Tecnologias Citrix
- Automação RDP
- Automação da Salesforce
- Automação SAP
- Automação do Varear Horizonte
- Geração de logs
- A ferramenta ScreenScrapeJavaSupport
- O protocolo Servodrive
- Test Suite — Studio
- Extensões
- Solução de problemas
- Sobre a solução de problemas
- Suporte e limitações do Microsoft Apo-V
- Solução de problemas do Internet Explorer x64
- Problemas do Microsoft Office
- Como identificar elementos de EU em PDF com opções de acessibilidade
- Reparando o suporte da Active Accessibility
- Automação de aplicativos em execução com um usuário diferente do Windows
- Validation of large Windows-legacy projects takes longer than expected
Guia do usuário do Studio
Como gerenciar dependências
As dependências do projeto no Studio se referem aos pacotes vinculados a um projeto específico, contendo atividades, seja padrão, seja personalizadas. As dependências são contextuais e consideram a definição de cada projeto, incluindo as atividades que ele usa, as variáveis e os argumentos de entrada/saída. Portanto, uma dependência será definida apenas se tiver pelo menos uma referência na definição do projeto.
No Studio, as dependências padrão para um projeto diferem dependendo do tipo de projeto, da compatibilidade ou do modelo usado para criar o projeto.
UiPath.System.Activities
UiPath.ComplexScenarios.Activities
, UiPath.Excel.Activities
, UiPath.Mail.Activities
, UiPath.Presentations.Activities
, UiPath.UIAutomation.Activities
, e UiPath.Word.Activities
.
project.json
.
O painel Projeto exibe os pacotes de atividades instalados no projeto de automação, junto com suas subdependências, regras de runtime, versões solicitadas e resolvidas. A compatibilidade do projeto é exibida no nó Dependências.
Passe o mouse sobre uma dependência para visualizar as versões solicitadas e resolvidas. Ações contextuais como Gerenciar, Reparar ou Remover Dependência estão disponíveis apenas para dependências e não seus subpacotes.
- Vermelho - A dependência não foi encontrada.
- Laranja - Um subpacote não foi encontrado.
- Cinza - A dependência não está resolvida.
- Azul desbotado - A versão resolvida é maior do que a versão solicitada.
- Azul intenso - Há uma correspondência exata entre a versão solicitada e a versão resolvida.
Para adicionar dependências a um projeto, instale-as a partir da janela Gerenciar pacotes. Observe que os pacotes disponíveis diferem com base na compatibilidade do projeto.
Sempre que novas versões estiverem disponíveis para as dependências do projeto atual, o botão botão Gerenciar Pacotes, da faixa de opções recebe um ícone de atualização .
-
Para gerenciar dependências em um projeto, clique com o botão direito do mouse na categoria Dependências, no painel Projeto e clique em Gerenciar. Isso abre a janela Gerenciar Pacotes, com a categoria Dependências do Projeto. O ícone mostra quais pacotes estão instalados atualmente.
- As dependências padrão são exibidas junto com as versões que estiverem vinculadas ao projeto no momento. Para atualizar um pacote, basta clicar no ícone de atualização , ao lado do número de versão disponível. O ícone é mostrado próximo ao pacote, significando que as dependências estão prontas para serem instaladas.
- As dependências são instaladas no projeto somente depois que você clicar em Salvar. Ao mesmo tempo, as versões das dependências são atualizadas no
project.json
arquivo pertencente ao projeto.
-
Para remover uma dependência do projeto, clique com o botão direito do mouse na dependência no painel do Projeto e depois em Remover dependência. A dependência é excluída do painel Projeto e do arquivo
project.json
.Alternativamente, vá em Gerenciar pacotes > Dependências do projeto, selecione a dependência a remover e então clique em Desinstalar.
- Para remover todas as dependências não usadas no projeto, selecione Remover não usadas > Dependências na faixa de opções do Studio ou use o atalho Ctrl + Shift + R. Todos os pacotes instalados que não possuem referências no projeto atual são removidos do painel Projeto e do arquivo
project.json
.
Se um fluxo de trabalho aberto no Studio tiver referências aos pacotes com versões que não estão disponíveis nos feeds do Studio atual, tais dependências serão marcadas como quebradas no painel Projeto e os detalhes serão disponibilidados no painel Saída.
O Studio permite que todas as dependências sejam reparadas em massa ou individualmente. Para reparar todas as dependências quebradas, clique com o botão direito do mouse no nó da Dependência, no painel Projeto e clique em Reparar Dependências.
Clique com o botão direito do mouse em uma dependência quebrada e selecione Resolver Dependência para repará-la individualmente. Alternativamente, é possível selecionar a opção Gerenciar para abrir a janela Gerenciar Pacotes e atualizá-los.
NuGet resolve dependências quebradas, aplicando a regra de runtime de Versão Mais Antiga Aplicável , o que significa que ele procura a primeira versão de pacote aplicável, superior àquela definida anteriormente.
Se a versão de destino não puder ser encontrada, a função de reparo usará automaticamente a próxima versão superior disponível. Observe que esse comportamento depende da configuração do feed.
Pacotes de atividades ficam disponíveis em várias versões e, por isso, ao instalá-los ou atualizá-los usando a janela Gerenciar pacotes, é possível definir regras de runtime de dependência para cada um deles.
A Regra de Runtime especifica qual versão do pacote a instalar no runtime. Ele apresenta duas opções disponíveis.
A regra de runtime Estrita é o estado padrão para dependências adicionadas na criação do processo e para os pacotes de atividades instalados a partir da janela Gerenciar Pacotes. Isso significa que apenas a versão especificada do pacote é usada no ambiente de execução no processo parent. A regra Estrita é marcada no painel Projeto, em Dependências pelo sinal , ao lado da versão do pacote.
A regra do ambiente de execução Versão mais antiga aplicável indica que se o pacote de destino não for encontrado, a próxima versão mais recente será pesquisada para resolver problemas de dependências. A regra Versão mais antiga aplicável é marcada no painel Projeto, em Dependências pelo sinal , ao lado da versão do pacote.
Ao executar um projeto de automação a partir do Studio, o robô faz o download da versão do pacote específica ou indicada da qual ele precisa para executar o projeto de acordo com as regras do ambiente de execução para cada projeto. Se a dependência usada durante a execução tiver uma regra de ambiente de execução Estrita e a versão de pacote exata não tiver sido encontrada, ocorrerá um erro. Para obter mais informações sobre como configurar regras de runtime para as dependências do projeto, confira a página Como gerenciar dependências.
A instalação de pacotes de atividades considera as regras de runtime de dependência definidas anteriormente para tais pacotes. Porém, alguns conflitos entre versões podem ocorrer durante a automatização dos projetos. Tanto o projeto de automação quanto a biblioteca que ele contém podem ter o mesmo pacote de atividades, mas com versões diferentes e regras de runtime. No momento do design, o NuGet resolve esses conflitos, escolhendo a dependência do nível superior, que é a mais próximo do projeto na hierarchy.
Explicamos abaixo a resolução dos conflitos que podem ocorrer:
O projeto contém um pacote de atividades com a versão 1.0. A biblioteca é referenciada ao projeto e usa o mesmo pacote, mas com uma versão mais recente. A dependência de nível superior v1.0 é usada no runtime. Um aviso será fornecido, mencionando a detecção de um downgrade.
A resolução desse cenário é aplicável independentemente da regra de runtime (Estrita ou Versão Mais Antiga Aplicável ) definida anteriormente para os pacotes de atividades.
- Se você escolher Sim, o pacote de atividades referenciado no projeto será atualizado para a versão usada na biblioteca.
-
Se você escolher Não, a janela Gerenciar Pacotes será aberta com a janela Dependências do Projeto.
O projeto contém um pacote de atividades com a versão 2.0. A biblioteca usa o mesmo pacote, mas com uma versão inferior e a regra de runtime Estrita . A dependência do nível superior usada neste caso será a v2.0 e um aviso será feito quando o pacote estiver instalado no projeto.
O projeto contém um pacote de atividades com a versão 2.0. A biblioteca usa o mesmo pacote, mas com uma versão inferior e a regra de runtime Versão Mais Antiga Aplicável. A dependência do nível superior usada neste caso será a v2.0 e um aviso será feito quando o pacote estiver instalado no projeto.
O projeto faz referência a uma biblioteca com um pacote de atividades versão 1.0 e a regra de runtime Estrita. O projeto faz referência a outra biblioteca, mas com um pacote de atividades versão versão 2.0. A dependência do nível superior neste caso é o pacote com v2.0, pois ele tem a versão mais alta. Um aviso será feito quando o pacote de atividades estiver instalado.
Neste conflito o projeto faz referências a duas bibliotecas, as quais, por sua vez, têm dependências Estritas mencionadas entre elas. Não há suporte para este cenário. Para obter informações detalhadas, confira a página Resolução de dependência.
UiPath.UIAutomation.Activities
. É recomendável evitar nomear seu projeto com o nome de um pacote já existente que você pretenda adicionar como uma dependência.
.xaml
arquivo de uma pasta chamada UiPath ou qualquer nome de um pacote existente que você pretenda adicionar como uma dependência, e não houver nenhum project.json
naquela pasta. project.json
Ao abrir um arquivo que não tem um .xaml
arquivo associado, o Studio cria um e a "name"
tag é preenchida com o nome da pasta parent.
Ao abrir um projeto com ou sem dependências, desenvolvido com uma versão anterior à v2018.3 (exceto para a v2016.2), o Studio solicitará a execução de uma migração automática, para que tente recuperar as dependências não encontradas e adicionar dependências padrão.
Após a confirmação, o Studio tenta recuperar dependências ausentes e define a regra de runtime estrita para os pacotes que ele encontra. Ao usar a opção Reparar Dependência, no painel Projeto, o Studio tenta instalar a próxima versão mais nova do projeto. Se a versão do pacote não for encontrada, serão exibidos alertas no painel Saída. Você deverá verificar os feeds configurados na janela Gerenciar Pacotes.
Os processos que contêm dependências e foram criados com versões do Studio anteriores à v2018.3 continuam a executar com o Robô v2018.3. A regra de runtime para esses projetos é definida como Versão mais baixa disponível.
project.json
arquivo. Ao abrir tais projetos, um alerta no painel Saída notificará você sobre dependências ausentes.Os pacotes da UiPath entregues localmente com o Studio são adicionados como dependências com a regra de runtime estrita. A versão mais recente desses pacotes é definida automaticamente.
Se tais projetos contêm pacotes diferentes dos fornecidos localmente com o Studio, recomendamos:
- Publicar o projeto usando a versão do Studio na qual ele foi criado, auxiliando, assim, o processo de migração por meio da adição de dependências no
project.json
arquivo ; - Instalar manualmente o pacote ausente, a partir da janela Gerenciar Pacotes, após configurar o feed necessário;
-
Usar a ferramenta Atualização em Massa de Dependências do Projeto para adicionar a dependência ausente para um grande número de projetos.
Observação: fluxos de trabalho contendo atividades inválidas não podem ser salvos. Instale a dependência necessária e, em seguida, salve o projeto.
UiPath.Platform.Activities
Os pacotes de atividades UiPath.V7.Activities
, e UiPath.Framework.Activities
foram descontinuados. Ao abrir projetos com UiPath.Framework.Activities
pacotes UiPath.Platform.Activities
e , o Studio v2018.3 ou superior tenta realizar uma migração automática para substituir as versões antigas das atividades pelas novas.
UiPath.V7.Activities
não podem ser migrados.
Existe uma solução alternativa, disponível para alguns casos nos quais a migração é é feita automaticamente.
- Abra o
project.json
arquivo com o Notepad++. - Remova o
"schemaVersion": "3.2"
parâmetro. - Substitua
"studioVersion"
por"toolVersion"
. - Altere o
"toolVersion"
valor de"18.3.xxx"
para uma versão anterior. Por exemplo, altere o valor de"18.3.0.958"
para"18.2.958"
. Salve o arquivo. -
Abra o
.xaml
arquivo com o Studio v2018.3 ou posterior para que a migração seja executada. Os pacotes de atividades descontinuados são substituídos por novos, conforme ilustrado na seção Dependências do painel Projeto.Observação: em alguns casos, os arquivos.xaml
que contêm os pacotesUiPath.Platform.Activities
eUiPath.Framework.Activities
não podem ser migrados automaticamente e a solução alternativa não é aplicável. Em situações como essas, o recomendado é abrir os projetos no Studio v2018.2 ou inferior, substituindo as atividades que pertencem aos pacotes mencionados acima pelas atividades contidas noUiPath.Core.Activities
pacote . O mesmo pode ser feito em relação aos fluxos de trabalho que contêm atividades doUiPath.V7.Activities
pacote.
UiPathStudio.msi
instalador .
Caso seja necessário reparar durante a migração de projetos contento tais pacotes como dependências, instale os dois pacotes a partir do feed Oficial ou de um feed local. Antes de executar tais projetos criados com versões anteriores à v2018.4.1, verifique se os pacotes acima estão disponíveis em um feed que o Robô possa acessar.
Se você fizer o upgrade de uma versão anterior à v2018.4.1, os dois pacotes de atividades permanecerão no feed Local.