Antes de entrar no desenvolvimento, é importante compilar uma base sólida para um novo projeto. Há vários modelos de projeto na comunidade de desenvolvedores do Dynamo que são excelentes locais para começar, mas uma compreensão de como iniciar um projeto do zero é ainda mais valiosa. A compilação de um projeto desde o início proporcionará uma compreensão mais profunda do processo de desenvolvimento.

Criar um projeto do Visual Studio

O Visual Studio é um IDE poderoso, onde podemos criar um projeto, adicionar referências, compilar .dlls e depurar. Ao criar um novo projeto, o Visual Studio também criará uma Solução, uma estrutura para organizar projetos. Vários projetos podem existir em uma única solução e podem ser compilados juntos. Para criar um nó Sem toque, precisaremos iniciar um novo projeto do Visual Studio no qual gravaremos uma biblioteca de classe C# e compilaremos um .dll.

Janela Novo projeto no Visual Studio

1. Começar abrindo o Visual Studio e criando um novo projeto: File > New > Project

2. Selecionar o modelo de projeto Class Library

3. Nomear o projeto (nomeamos o projeto MyCustomNode)

4. Definir o caminho do arquivo para o projeto. Para este exemplo, vamos deixá-lo na localização padrão

5. Selecionar Ok

O Visual Studio criará e abrirá automaticamente um arquivo C#. Deve ser atribuído um nome apropriado, deve ser configurado o espaço de trabalho e substituído o código padrão por este método de multiplicação.

 namespace MyCustomNode
 {
     public class SampleFunctions
     {
         public static double MultiplyByTwo(double inputNumber)
         {
             return inputNumber * 2.0;
         }
     }
 }

1. Abrir o Gerenciador de soluções e as janelas Saída em View.

2. Renomear o arquivo Class1.cs SampleFunctions.cs no Gerenciador de soluções à direita.

3. Adicionar o código acima para a função de multiplicação. Abordaremos as especificações de como o Dynamo lerá as classes C# mais adiante.

4. O Gerenciador de soluções fornece acesso a tudo no projeto.

5. Janela Saída: precisaremos dela mais tarde para ver se a compilação foi bem-sucedida.

A próxima etapa é compilar o projeto, mas antes de fazer isso, há algumas configurações que precisamos verificar. Primeiro, assegure-se de que Any CPU ou x64 esteja selecionado como o destino da plataforma e que Prefer 32-bit esteja desmarcado nas Propriedades do projeto.

1. Abrir as propriedades do projeto selecionando Project > "ProjectName" Properties

2. Selecionar a página Build

3. Selecionar Any CPU ou x64 no menu suspenso

4. Garantir que Prefer 32-bit está desmarcado

Agora podemos compilar o projeto para criar um .dll. Para isso, selecione Build Solution no menu Build ou use o atalho CTRL+SHIFT+B.

1. Selecionar Build > Build Solution

2. É possível determinar se o projeto foi compilado com êxito verificando a janela Saída

Se o projeto tiver sido compilado com êxito, haverá um .dll nomeado MyCustomNode na pasta do projeto bin. Para este exemplo, deixamos o caminho de arquivo do projeto como padrão do Visual Studio em c:\users\username\documents\visual studio 2015\Projects. Vamos dar uma olhada na estrutura de arquivos do projeto.

1. A pasta bin contém o .dll criado no Visual Studio.

2. O arquivo de projeto do Visual Studio.

3. O arquivo de classe.

4. Como nossa configuração de solução foi definida como Debug, o .dll será criado em bin\Debug.

Agora, podemos abrir o Dynamo e importar o .dll. Com o recurso Adicionar, navegue até a localização do projeto bin e selecione o .dll que deseja abrir.

1. Selecionar o botão Adicionar para importar um .dll

2. Navegar até a localização do projeto. Nosso projeto está localizado no caminho de arquivo padrão do Visual Studio: C:\Users\username\Documents\Visual Studio 2015\Projects\MyCustomNode

3. Selecionar o MyCustomNode.dll a ser importado

4. Clicar em Open para carregar o .dll

Se uma categoria for criada na biblioteca chamada MyCustomNode, significa que o .dll foi importado com êxito. No entanto, o Dynamo criou dois nós do que queríamos ser um nó único. Na próxima seção, explicaremos por que isso acontece e como o Dynamo lê um .dll.

1. MyCustomNode na biblioteca do Dynamo. A categoria da biblioteca é determinada pelo nome .dll.

2. SampleFunctions.MultiplyByTwo na tela.

Como o Dynamo lê as classes e os métodos

Quando o Dynamo carrega um .dll, ele expõe todos os métodos estáticos públicos como nós. Construtores, métodos e propriedades serão transformados em nós Criar, Ação e Consulta, respectivamente. No nosso exemplo de multiplicação, o método MultiplyByTwo() se torna num nó Ação no Dynamo. Isso ocorre porque o nó foi nomeado com base em seu método e classe.

1. A entrada é nomeada inputNumber com base no nome do parâmetro do método.

2. A saída é nomeada double por padrão porque esse é o tipo de dados que está sendo retornado.

3. O nó é nomeado SampleFunctions.MultiplyByTwo porque esses são os nomes de classe e método.

No exemplo acima, o nó adicional Criar SampleFunctions foi criado porque não fornecemos explicitamente um construtor e, portanto, um foi criado automaticamente. Podemos evitar isso criando um construtor privado vazio em nossa classe SampleFunctions.

namespace MyCustomNode
{
    public class SampleFunctions
    {
        //The empty private constructor.
        //This will be not imported into Dynamo.
        private SampleFunctions() { }

        //The public multiplication method. 
        //This will be imported into Dynamo.
        public static double MultiplyByTwo(double inputNumber)
        {
            return inputNumber * 2.0;
        }
    }
}

1. O Dynamo importou nosso método como um nó Criar

Adicionar referências do pacote NuGet do Dynamo

O nó de multiplicação é muito simples e não é necessário fazer referências ao Dynamo. Se quisermos acessar qualquer funcionalidade do Dynamo para criar geometria, por exemplo, precisaremos fazer referência aos pacotes NuGet do Dynamo.

• ZeroTouchLibrary – Pacote para a compilação de bibliotecas de nós sem toque para o Dynamo que contém as seguintes bibliotecas: DynamoUnits.dll, ProtoGeometry.dll

• WpfUILibrary – Pacote para bibliotecas de nós de compilação do Dynamo com interface de usuário personalizada no WPF que contém as seguintes bibliotecas: DynamoCoreWpf.dll, CoreNodeModels.dll, CoreNodeModelWpf.dll

• DynamoServices – Biblioteca do DynamoServices para o Dynamo

• Core – Infraestrutura de teste da unidade e do sistema para o Dynamo que contém as seguintes bibliotecas: DSIronPython.dll, DynamoApplications.dll, DynamoCore.dll, DynamoInstallDetetive.dll, DynamoShapeManager.dll, DynamoUtilities.dll, ProtoCore.dll, VMDataBridge.dll

• Tests – Infraestrutura de teste da unidade e do sistema para o Dynamo que contém as seguintes bibliotecas: DynamoCoreTests.dll, SystemTestServices.dll, TestServices.dll

• DynamoCoreNodes – Pacote para a compilação de nós principais do Dynamo que contém as seguintes bibliotecas: Analysis.dll, GeometryColor.dll, DSCoreNodes.dll

Para fazer referência a esses pacotes em um projeto do Visual Studio, faça o download do pacote NuGet nos links acima e faça referência manualmente aos .dlls ou use o Gerenciador de pacotes NuGet no Visual Studio. Primeiro, podemos analisar como instalá-los com o NuGet no Visual Studio.

1. Abra o Gerenciador de pacotes NuGet selecionando Tools > NuGet Package Manager > Manage NuGet Packages for Solution...

Esse é o Gerenciador de pacotes NuGet. Essa janela mostra quais pacotes foram instalados para o projeto e permite que o usuário procure outros. Se uma nova versão do pacote DynamoServices for liberada, os pacotes poderão ser atualizados daqui ou revertidos para uma versão anterior.

1. Selecionar Procurar e pesquisar DynamoVisualProgramming para ativar os pacotes do Dynamo.

2. Pacotes do Dynamo. Selecionar um mostrará a versão atual e a descrição do que está dentro.

3. Selecionar a versão do pacote necessária e clicar em instalar. Isso instala um pacote para o projeto específico no qual você está trabalhando. Como estamos usando a versão estável mais recente do Dynamo, a versão 1.3, escolha a versão do pacote correspondente.

Para adicionar manualmente um pacote transferido por download do navegador, abra o Gerenciador de referências no Gerenciador de soluções e procure o pacote.

1. Clicar com o botão direito do mouse em References e selecionar Add Reference.

2. Selecionar Browse para navegar para a localização do pacote.

Agora que o Visual Studio está configurado corretamente e adicionamos com êxito um .dll ao Dynamo, temos uma base sólida para os conceitos daqui para frente. Este é apenas o início, portanto, siga em frente para saber mais sobre como criar um nó personalizado.

Independentemente do nível de experiência, a plataforma do Dynamo foi projetada para que todos os usuários sejam colaboradores. Há diversas opções de desenvolvimento voltadas para diferentes capacidades e níveis de habilidades, cada uma com seus pontos fortes e fracos, dependendo do objetivo. Abaixo, descreveremos as diferentes opções e como escolher uma em detrimento de outra.

Três ambientes de desenvolvimento: Visual Studio, Editor do Python e DesignScript com Blocos de código

Quais são as minhas opções?

As opções de desenvolvimento do Dynamo são divididas principalmente em duas categorias: para o Dynamo versus no Dynamo. As duas categorias podem ser consideradas semelhantes; “no” Dynamo implica o conteúdo criado usando o IDE do Dynamo para ser usado no Dynamo e “para” o Dynamo implica o uso de ferramentas externas para criar conteúdo a ser importado para o Dynamo para ser usado. Embora este guia se concentre no desenvolvimento para o Dynamo, os recursos para todos os processos são descritos abaixo.

Para o Dynamo

Estes nós permitem o maior grau de personalização. Muitos pacotes são criados com esse método e é necessário para contribuir para a origem do Dynamo. O processo de compilação deles será abordado neste guia.

• Nós Sem toque

• Nós derivados do NodeModel

• Extensões

Para a discussão abaixo, o Visual Studio é usado como o ambiente de desenvolvimento para os nós Sem toque e NodeModel.

A interface do Visual Studio com um projeto que desenvolveremos

No Dynamo

• Os Blocos de código expõem o DesignScript no ambiente de programação visual, permitindo fluxos de trabalho flexíveis de scripts de texto e nós. Uma função em um bloco de código pode ser chamada por qualquer item no espaço de trabalho.

• Os nós personalizados são contêineres para coleções de nós ou até mesmo gráficos inteiros. Eles são uma forma eficaz de coletar rotinas usadas com frequência e compartilhá-las com a comunidade.

• Os nós Python são uma interface de scripts no espaço de trabalho de programação visual, semelhante aos blocos de código. As bibliotecas Autodesk.DesignScript usam uma notação de ponto similar ao DesignScript.

O desenvolvimento no espaço de trabalho do Dynamo é uma ferramenta poderosa para obter feedback imediato.

Desenvolvimento no espaço de trabalho do Dynamo com o nó Python

Quais são as vantagens/desvantagens de cada um?

As opções de desenvolvimento do Dynamo foram projetadas para lidar com a complexidade de uma necessidade de personalização. Se o objetivo é escrever um script recursivo no Python ou compilar uma interface de usuário de nó totalmente personalizada, há opções para implementar código que envolvem apenas o que é necessário para começar a trabalhar.

Blocos de código, nó Python e nós personalizados no Dynamo

Essas são opções simples para escrever código no ambiente de programação visual do Dynamo. O espaço de trabalho de programação visual do Dynamo fornece acesso ao Python, ao DesignScript e à capacidade de conter vários nós dentro de um nó personalizado.

Com esses métodos, podemos:

• Começar a escrever Python ou DesignScript com pouca ou nenhuma configuração.

• Importar bibliotecas Python para o Dynamo.

• Compartilhar blocos de código, nós Python e nós personalizados com a comunidade do Dynamo como parte de um pacote.

Nós Sem toque

O nó Sem toque é um método simples de apontar e clicar para importar bibliotecas C#. O Dynamo lê os métodos públicos de um .dll e os converte em nós do Dynamo. É possível usar o nó Sem toque para desenvolver seus próprios nós e pacotes personalizados.

Com esse método, podemos:

• Escrever métodos C# e usar facilmente os métodos como nós no Dynamo

• Compartilhar uma biblioteca C# como nós com a comunidade do Dynamo em um pacote

Nós derivados do NodeModel

Esses nós são um passo mais profundo na estrutura do Dynamo. Eles são baseados na classe NodeModel e escritos em C#. Embora esse método forneça a maior flexibilidade e potência, a maioria dos aspectos do nó precisa ser explicitamente definida e as funções precisam residir em uma montagem separada.

Com esse método, podemos:

• Criar uma interface de usuário de nó totalmente personalizável com controles deslizantes, imagens, cores etc. (por exemplo, nó ColorRange)

• Acessar e afetar o que está acontecendo na tela do Dynamo

• Personalizar a amarra

• Carregar no Dynamo como um pacote

Entender o controle de versão do Dynamo e as alterações da API (1.x → 2.x)

Como o Dynamo está sendo atualizado regularmente, as alterações podem ser feitas em parte da API que um pacote usa. O rastreamento dessas alterações é importante para garantir que os pacotes existentes continuem a funcionar corretamente.

Permissão para distribuir binários em um pacote

Esteja ciente de que os .dll estão incluídos em um pacote que está sendo carregado no gerenciador de pacotes. Se o autor do pacote não tiver criado o .dll, ele deverá ter os direitos para compartilhá-lo.

Se um pacote incluir binários, os usuários deverão ser informados, ao fazer o download, de que o pacote contém binários.

Os nós baseados no NodeModel fornecem significativamente mais flexibilidade e potência do que os nós Sem toque. Neste exemplo, levaremos o nó de grade Sem toque para o próximo nível ao adicionar um controle deslizante integrado que randomiza o tamanho do retângulo.

O controle deslizante dimensiona as células em relação a seu tamanho, de modo que o usuário não precise fornecer um controle deslizante com o intervalo correto.

Padrão “Model-View-Viewmodel”

Em um alto nível, há duas partes para estabelecer uma relação de vista de modelo no Dynamo:

• Uma classe NodeModel para estabelecer a lógica central do nó (o “modelo”)

• Uma classe INodeViewCustomization para personalizar como o NodeModel está sendo visualizado (a “vista”)

Os objetos NodeModel já têm um modelo de vista associado (NodeViewModel), portanto, podemos nos concentrar no modelo e na vista para a interface do usuário personalizada.

Como implementar o NodeModel

Os nós NodeModel têm diversas diferenças significativas dos nós Sem toque que abordaremos neste exemplo. Antes de passarmos para a personalização da interface do usuário, vamos começar compilando a lógica do NodeModel.

1. Criar a estrutura do projeto:

Um nó NodeModel pode chamar somente funções, portanto, precisamos separar o NodeModel e as funções em diferentes bibliotecas. A forma padrão de fazer isso para pacotes do Dynamo é criar projetos separados para cada um. Comece criando uma nova solução para englobar os projetos.

1. Selecionar File > New > Project

2. Selecionar Other Project Types para ativar a opção Solução

3. Selecionar Blank Solution

4. Nomear a solução CustomNodeModel

5. Selecionar Ok

Crie dois projetos de biblioteca de classes C# na solução: um para as funções e outro para implementar a interface NodeModel.

1. Clicar com o botão direito do mouse na Solução e selecionar Add > New Project

2. Escolher a biblioteca de classes

3. Nomeá-la CustomNodeModel

4. Clicar em Ok

5. Repita o processo para adicionar outro projeto nomeado CustomNodeModelFunctions

Em seguida, precisamos renomear as bibliotecas de classes que foram criadas automaticamente e adicionar uma ao projeto CustomNodeModel. A classe GridNodeModel implementa a classe NodeModel abstrata, GridNodeView é usada para personalizar a vista e GridFunction contém as funções que precisamos chamar.

1. Adicionar outra classe clicando com o botão direito do mouse no projeto CustomNodeModel, selecionando Add > New Item... e escolhendo Class.

2. No projeto CustomNodeModel, precisamos das classes GridNodeModel.cs e GridNodeView.cs

3. No projeto CustomNodeModelFunction, precisamos de uma classe GridFunctions.cs

Antes de adicionarmos qualquer código às classes, adicione os pacotes necessários para este projeto. CustomNodeModel precisará de ZeroTouchLibrary e WpfUILibrary e CustomNodeModelFunction só precisará de ZeroTouchLibrary. A biblioteca WpfUIL será usada na personalização da interface do usuário que faremos mais tarde, e a biblioteca ZeroTouchLibrary será usada para criar a geometria. É possível adicionar os pacotes individualmente para os projetos. Como esses pacotes têm dependências, o Core e o DynamoServices serão instalados automaticamente.

1. Clicar com o botão direito do mouse em um projeto e selecionar Manage NuGet Packages

2. Instalar somente os pacotes necessários para aquele projeto

O Visual Studio copiará os pacotes NuGet aos quais fizemos referência para o diretório de compilação. Isso pode ser definido como false, para que não tenhamos arquivos desnecessários no pacote.

1. Selecionar pacotes do Dynamo NuGet

2. Definir Copy Local como false

2. Herdar a classe NodeModel

Como mencionado anteriormente, o aspecto principal que torna um nó NodeModel diferente de um nó Sem toque é a implementação da classe NodeModel. Um nó NodeModel precisa de diversas funções dessa classe, e podemos obtê-las adicionando :NodeModel após o nome da classe.

Copie o seguinte código para o GridNodeModel.cs.

Isso é diferente dos nós Sem toque. Vamos entender o que cada parte está fazendo.

• Especificar os atributos do nó, como nomes Name, Category, InPort/OutPort, tipos InPort/OutPort e descrições.

• public class GridNodeModel : NodeModel é uma classe que herda a classe NodeModel de Dynamo.Graph.Nodes.

• public GridNodeModel() { RegisterAllPorts(); } é um construtor que registra as entradas e saídas do nó.

• BuildOutputAst() retorna um AST (Abstract Syntax Tree), a estrutura necessária para retornar os dados de um nó NodeModel.

• AstFactory.BuildFunctionCall() chama a função RetangularGrid de GridFunctions.cs.

• new Func<int, int, double, List<Rectangle>>(GridFunction.RectangularGrid) especifica a função e seus parâmetros.

• new List<AssociativeNode> { inputAstNodes[0], inputAstNodes[1], sliderValue }); mapeia as entradas do nó para parâmetros de função

• AstFactory.BuildNullNode() compilará um nó nulo se as portas de entrada não estiverem conectadas. Isso é para evitar a exibição de um aviso no nó.

• RaisePropertyChanged("SliderValue") notifica a interface do usuário quando o valor do controle deslizante é alterado

• var sliderValue = AstFactory.BuildDoubleNode(SliderValue) compila um nó no AST que representa o valor do controle deslizante

• Alterar uma entrada para a variável sliderValue na variável functionCall new List<AssociativeNode> { inputAstNodes[0], sliderValue });

3. Chamar uma função

O projeto CustomNodeModelFunction será compilado em uma montagem separada de CustomNodeModel para que possa ser chamado.

Copie o seguinte código para GridFunction.cs.

Essa classe de função é muito similar ao estudo de caso de Grade sem Toque, com uma diferença:

• [IsVisibleInDynamoLibrary(false)] impede que o Dynamo “veja” o seguinte método e classe, já que a função já está sendo chamada de CustomNodeModel.

Assim como adicionamos referências para pacotes NuGet, CustomNodeModel precisará fazer referência a CustomNodeModelFunction para chamar a função.

A declaração de uso para CustomNodeModel estará inativa até que a função seja referenciada

1. Clicar com o botão direito do mouse em CustomNodeModel e selecionar Add > Reference

2. Escolher Projects > Solution

3. Marcar CustomNodeModelFunction

4. Clicar em Ok

4. Personalizar a vista

Para criar um controle deslizante, é preciso personalizar a interface do usuário implementando a interface do INodeViewCustomization.

Copie o seguinte código para GridNodeView.cs

• public class CustomNodeModelView : INodeViewCustomization<GridNodeModel> define as funções necessárias para personalizar a interface do usuário.

Após a estrutura do projeto ter sido configurada, use o ambiente de projeto do Visual Studio para compilar um controle de usuário e definir seus parâmetros em um arquivo .xaml. Na caixa de ferramentas, adicione um controle deslizante a <Grid>...</Grid>.

1. Clicar com o botão direito do mouse em CustomNodeModel e selecionar Add > New Item

2. Selecionar WPF

3. Nomear o controle de usuário Slider

4. Clicar em Add

Copie o seguinte código para Slider.xaml

• Os parâmetros do controle deslizante são definidos no arquivo .xaml. Os atributos Mínimo e Máximo definem o intervalo numérico dessa barra deslizante.

• Dentro de <Grid>...</Grid>, podemos colocar diferentes controles de usuário na caixa de ferramentas do Visual Studio

Quando criamos o arquivo Slider.xaml, o Visual Studio criou automaticamente um arquivo C# chamado Slider.xaml.cs que inicializa o controle deslizante. Altere o namespace nesse arquivo.

• O namespace deve ser CustomNodeModel.CustomNodeModel

O GridNodeModel.cs define a lógica de cálculo do controle deslizante.

5. Configurar como um pacote

Antes de compilarmos o projeto, a etapa final é adicionar um arquivo pkg.json para que o Dynamo possa ler o pacote.

1. Clicar com o botão direito do mouse em CustomNodeModel e selecionar Add > New Item

2. Selecionar Web

3. Selecionar JSON File

4. Nomear o arquivo pkg.json

5. Clicar em Add

• Copie o seguinte código para pkg.json

• "name": determina o nome do pacote e seu grupo na biblioteca do Dynamo

• "keywords": fornece termos de pesquisa para pesquisar na biblioteca do Dynamo

• "node_libraries": [] as bibliotecas associadas ao pacote

  A última etapa é compilar a solução e publicar como um pacote do Dynamo. Consulte o capítulo Implantação do pacote para saber como criar um pacote local antes de publicar on-line e como compilar um pacote diretamente do Visual Studio.

Introdução

Esta seção contém informações sobre problemas que podem ocorrer durante a migração dos gráficos, dos pacotes e das bibliotecas para o Dynamo 3.x.

O Dynamo 3.0 é uma versão principal e algumas APIs foram alteradas ou removidas. A maior alteração que provavelmente afetará você como desenvolvedor ou usuário do Dynamo 3.x é a mudança para .NET8.

Dotnet/.NET é o tempo de execução que alimenta a linguagem C# na qual o Dynamo está escrito. Atualizamos para uma versão moderna deste tempo de execução junto com o resto do ecossistema da Autodesk.

Você pode ler mais em nossa postagem de blog.

Compatibilidade dos pacotes

Usar pacotes do Dynamo 2.x no Dynamo 3.x

Como o Dynamo 3.x agora é executado no tempo de execução do .NET8, não é garantido que os pacotes que foram criados para o Dynamo 2.x (usando o .NET48) funcionem no Dynamo 3.x. Quando você tentar fazer download de um pacote no Dynamo 3.x que foi publicado de uma versão do Dynamo inferior a 3.0, receberá um aviso de que o pacote é de uma versão anterior do Dynamo.

Isso não significa que o pacote não funcionará É simplesmente um aviso de que podem ocorrer problemas de compatibilidade e, em geral, é uma boa ideia verificar se há uma versão mais recente que tenha sido criada especificamente para o Dynamo 3.x.

Você também pode observar esse tipo de aviso nos arquivos de registro do Dynamo no momento da carga do pacote. Se tudo estiver funcionando corretamente, será possível ignorá-lo.

Usar pacotes do Dynamo 3.x no Dynamo 2.x

É muito improvável que um pacote criado para o Dynamo 3.x (usando .Net8) funcione no Dynamo 2.x. Você também verá um aviso ao fazer o download de pacotes criados para versões mais recentes do Dynamo enquanto usa uma versão mais antiga.

O Dynamo depende da criatividade e do compromisso de sua comunidade, e a equipe do Dynamo incentiva os colaboradores a explorar possibilidades, testar ideias e envolver a comunidade para enviar feedback. Embora a inovação seja altamente encorajada, as alterações só serão mescladas se facilitarem o uso do Dynamo e satisfizerem as diretrizes definidas neste documento. As alterações com benefícios pouco definidos não serão incorporadas.

Expectativas das solicitações de extração

A equipe do Dynamo espera que as solicitações de extração sigam algumas diretrizes:

• Siga nossos padrões de codificação e padrões de nomenclatura de nós

• Inclua testes de unidade durante a adição de novos recursos

• Ao corrigir um erro, adicione um teste de unidade que realce como o comportamento atual é quebrado

• Mantenha a discussão focada em um problema. Crie um novo problema se um tópico novo ou relacionado for exibido.

E algumas diretrizes sobre o que não fazer:

• Surpreender-nos com grandes pedidos de extração. Em vez disso, registre um problema e inicie uma discussão para que possamos concordar sobre a abordagem a ser seguida antes de investir um grande tempo.

• Confirmar o código que você não escreveu. Se você encontrar um código que você acha que é uma boa opção para adicionar ao Dynamo, registre um problema e inicie uma discussão antes de continuar.

• Enviar representações posicionais que alteram os arquivos ou cabeçalhos relacionados ao licenciamento. Se você achar que há um problema com eles, envie um problema e ficaremos felizes em discuti-lo.

• Fazer adições de API sem apresentar um problema e discuti-lo conosco primeiro.

Preencher o modelo de solicitação de extração

Ao enviar uma solicitação de extração, use o modelo PR padrão. Antes de enviar a representação posicional, certifique-se de que o propósito esteja claramente descrito e que todas as declarações possam ser afirmadas como verdadeiras:

• A base de código está em um estado melhor após esta representação posicional

• É documentado de acordo com as normas

• O nível de teste que esta representação posicional inclui é apropriado

• Sequências de caracteres voltadas para o usuário, se existirem, são extraídas para arquivos *.resx

• Todos os testes passam usando o CI de autoatendimento

• Instantâneo das alterações da interface do usuário, se houver

• As alterações na API seguem a Versão semântica e são documentadas no documento Alterações da API.

Um revisor apropriado será atribuído à solicitação de extração pela equipe do Dynamo.

Processo de revisão das solicitações de extração

Depois de uma solicitação de extração ser enviada, talvez seja necessário permanecer envolvido durante o processo de revisão. Esteja ciente dos seguintes critérios de revisão:

• A equipe do Dynamo se reúne uma vez por mês para analisar as solicitações de extração das mais antigas para as mais recentes.

• Se uma solicitação de extração revisada exigir alterações pelo proprietário, o proprietário da representação posicional terá 30 dias para responder. Se a representação posicional não tiver registrado nenhuma atividade na próxima sessão, ela será fechada pela equipe ou, dependendo de sua utilidade, será assumida por alguém da equipe.

• As solicitações de extração devem usar o modelo de RP padrão do Dynamo

• As solicitações de extração que não têm os modelos de RP do Dynamo completamente preenchidos com todas as declarações satisfeitas não serão revisadas.

Escolha seletiva de confirmações do Dynamo Revit

Como há várias versões do Revit disponíveis no mercado, talvez seja necessário escolher cuidadosamente as alterações em ramificações específicas da versão do DynamoRevit para que diferentes versões do Revit possam obter a nova funcionalidade. Durante o processo de revisão, os colaboradores serão responsáveis por selecionar cuidadosamente suas confirmações revisadas para as outras ramificações do DynamoRevit, conforme especificado pela equipe do Dynamo.

Extensões como pacotes

Visão geral

As extensões do Dynamo podem ser implantadas no gerenciador de pacotes, como as bibliotecas de nós normais do Dynamo. Quando um pacote instalado contém uma extensão de vista, a extensão é carregada no tempo de execução quando o Dynamo é carregado. É possível verificar o console do Dynamo para verificar se a extensão foi carregada corretamente.

Estrutura do pacote

A estrutura de um pacote de extensão é a mesma que um pacote normal contendo...

C:\Users\User\AppData\Roaming\Dynamo\Dynamo Core\2.1\packages\Sample View Extension
│   pkg.json
├───bin
│       SampleViewExtension.dll
├───dyf
└───extra
        SampleViewExtension_ViewExtensionDefinition.xml

Presumindo que você já tenha compilado a extensão, terá (no mínimo) uma montagem .NET e um arquivo de manifesto. A montagem deve conter uma classe que implementa IViewExtension ou IExtension. O arquivo de manifesto .XML informa ao Dynamo qual classe deve ser instanciada para iniciar a extensão. Para que o gerenciador de pacotes localize corretamente a extensão, o arquivo de manifesto deve corresponder com precisão à localização e à nomenclatura da montagem.

Coloque os arquivos de montagem na pasta bin e o arquivo de manifesto na pasta extra. Também é possível colocar todos os recursos adicionais nessa pasta.

Exemplo de arquivo .XML de manifesto:

<ViewExtensionDefinition>
  <AssemblyPath>..\bin\MyViewExtension.dll</AssemblyPath>
  <TypeName>MyViewExtension.MyViewExtension</TypeName>
</ViewExtensionDefinition>

Carregar

Depois que você tiver uma pasta contendo os subdiretórios descritos acima, estará pronto para enviar (carregar) para o gerenciador de pacotes. Um ponto a ter em mente é que não é possível publicar pacotes do Dynamo Sandbox. Isso significa que é necessário estar usando o Dynamo Revit. Uma vez dentro do Dynamo Revit, navegue até Pacotes => Publicar novo pacote. Isso solicitará que o usuário faça login na Autodesk Account com a qual deseja associar o pacote.

Neste ponto, você deve estar na janela normal do pacote de publicação, onde será necessário inserir todos os campos obrigatórios relativos ao pacote/extensão. Há uma etapa adicional muito importante que requer que você assegure que nenhum dos arquivos de montagem esteja marcado como uma biblioteca de nós. Isso é feito clicando com o botão direito do mouse nos arquivos importados (a pasta de pacotes criada acima). Um menu de contexto será exibido, o que lhe dá a opção de marcar (ou desmarcar) essa opção. Todas as montagens de extensão devem estar desmarcadas.

Antes de publicar de forma pública, você deve sempre publicar localmente para assegurar que tudo funcione como esperado. Uma vez que isso tenha sido verificado, você estará pronto para entrar em ação selecionando Publicar.

Extrair

Para verificar se o pacote foi carregado com êxito, você deverá ser capaz de pesquisá-lo com base na nomeação e nas palavras-chave especificadas na etapa de publicação. Por fim, é importante observar que as mesmas extensões exigirão uma reinicialização do Dynamo antes de funcionar. Normalmente, essas extensões exigem parâmetros especificados quando o Dynamo é inicializado.

Executar scripts Python em nós sem toque (C#)

Se você estiver familiarizado com a escrita de scripts no Python e desejar mais funcionalidade dos nós padrão do Dynamo Python, poderemos usar o recurso Sem toque para criar nossos próprios. Vamos começar com um exemplo simples que nos permite passar um script Python como uma sequência de caracteres para um nó Sem toque, onde o script é executado e um resultado é retornado. Este estudo de caso será baseado nos tutoriais virtuais e nos exemplos na seção Introdução. Consulte os exemplos se você for completamente novo na criação de nós Sem toque.

Um nó Sem toque que executará uma sequência de caracteres de script Python

Mecanismo Python

Esse nó depende de uma instância do mecanismo de scripts IronPython. Para fazer isso, precisamos fazer referência a algumas montagens adicionais. Siga as etapas abaixo para configurar um modelo básico no Visual Studio:

• Criar um novo projeto de classe do Visual Studio

• Adicionar uma referência ao IronPython.dll localizado em C:\Program Files (x86)\IronPython 2.7\IronPython.dll

• Adicionar uma referência ao Microsoft.Scripting.dll localizado em C:\Program Files (x86)\IronPython 2.7\Platforms\Net40\Microsoft.Scripting.dll

• Incluir as declarações IronPython.Hosting e Microsoft.Scripting.Hosting using na classe

• Adicionar um construtor vazio privado para evitar que um nó adicional seja adicionado à biblioteca do Dynamo com nosso pacote

• Criar um novo método que toma uma única sequência de caracteres como um parâmetro de entrada

• Dentro desse método, instanciaremos um novo mecanismo Python e criaremos um escopo de script vazio. Você pode imaginar esse escopo como as variáveis globais dentro de uma instância do interpretador Python

• Em seguida, chamar Execute no mecanismo que está passando a sequência de entrada e o escopo como parâmetros

• Por fim, recuperar e retornar os resultados do script chamando GetVariable no escopo e passando o nome da variável do script Python que contém o valor que você está tentando retornar. (Consulte o exemplo abaixo para obter detalhes adicionais)

O código a seguir fornece um exemplo para a etapa mencionada acima. A compilação da solução criará um novo .dll localizado na pasta bin de nosso projeto. Agora, é possível importar este .dll para o Dynamo como parte de um pacote ou navegar para File < Import Library...

using IronPython.Hosting;
using Microsoft.Scripting.Hosting;

namespace PythonLibrary
{
    public class PythonZT
    {
        // Unless a constructor is provided, Dynamo will automatically create one and add it to the library
        // To avoid this, create a private constructor
        private PythonZT() { }

        // The method that executes the Python string
        public static string executePyString(string pyString)
        {
            ScriptEngine engine = Python.CreateEngine();
            ScriptScope scope = engine.CreateScope();
            engine.Execute(pyString, scope);
            // Return the value of the 'output' variable from the Python script below
            var output = scope.GetVariable("output");
            return (output);
        }
    }
}

O script Python está retornando a variável output, o que significa que precisaremos de uma variável output no script Python. Use esse script de amostra para testar o nó no Dynamo. Se você já tiver usado o nó Python no Dynamo, o seguinte deverá ser familiar. Para obter mais informações, consulte a seção Python do manual.

import clr
clr.AddReference('ProtoGeometry')
from Autodesk.DesignScript.Geometry import *

cube = Cuboid.ByLengths(10,10,10);
volume = cube.Volume
output = str(volume)

Várias saídas

Uma limitação dos nós Python padrão é que eles têm somente uma única porta de saída, portanto, se desejarmos retornar vários objetos, deveremos criar uma lista e recuperar cada objeto. Se modificarmos o exemplo acima para retornar um dicionário, poderemos adicionar quantas portas de saída desejarmos. Consulte a seção Retornar vários valores em “Aprofundar o conhecimento sobre o nó Sem toque” para obter informações mais específicas sobre os dicionários.

Esse nó está nos permitindo retornar o volume do cuboide e seu centroide.

Vamos modificar o exemplo anterior com estas etapas:

• Adicionar uma referência ao DynamoServices.dll do gerenciador de pacotes do NuGet

• Além das montagens anteriores, incluir System.Collections.Generic e Autodesk.DesignScript.Runtime

• Modificar o tipo de retorno em nosso método para retornar um dicionário que conterá nossas saídas

• Cada saída deve ser individualmente recuperada do escopo (considere a possibilidade de configurar um loop simples para conjuntos maiores de saídas)

using IronPython.Hosting;
using Microsoft.Scripting.Hosting;
using System.Collections.Generic;
using Autodesk.DesignScript.Runtime;

namespace PythonLibrary
{
    public class PythonZT
    {
        private PythonZT() { }

        [MultiReturn(new[] { "output1", "output2" })]
        public static Dictionary<string, object> executePyString(string pyString)
        {
            ScriptEngine engine = Python.CreateEngine();
            ScriptScope scope = engine.CreateScope();
            engine.Execute(pyString, scope);
            // Return the value of 'output1' from script
            var output1 = scope.GetVariable("output1");
            // Return the value of 'output2' from script
            var output2 = scope.GetVariable("output2");
            // Define the names of outputs and the objects to return
            return new Dictionary<string, object> {
                { "output1", (output1) },
                { "output2", (output2) }
            };
        }
    }
}

Também adicionamos uma variável de saída (output2) ao script python de amostra. Lembre-se de que essas variáveis podem usar qualquer convenção de nomenclatura Python legal, a saída foi usada estritamente para fins de clareza neste exemplo.

import clr
clr.AddReference('ProtoGeometry')
from Autodesk.DesignScript.Geometry import *

cube = Cuboid.ByLengths(10,10,10);
centroid = Cuboid.Centroid(cube);
volume = cube.Volume
output1 = str(volume)
output2 = str(centroid)

Qual é o propósito deste guia?

O objetivo deste guia é ajudar você a navegar pela gama de possibilidades de desenvolvimento em C# para o Dynamo, desde como criar nós sem toque até extensões de compilação.

Origem do Dynamo no GitHub

Que recursos adicionais de desenvolvedor fornecemos?

Dynamo: faça o download das mais recentes compilações estáveis e diárias do Dynamo

https://dynamobuilds.com/

Dynamo GitHub: o Dynamo é um projeto de desenvolvimento de código aberto no GitHub.

https://github.com/DynamoDS/Dynamo

Wiki do Dynamo Github: esse foi o recurso principal para a documentação do desenvolvedor.

https://github.com/DynamoDS/Dynamo/wiki

Normas de nomenclatura dos nós: fornecem normas e diretrizes para nomear categorias, nós e portas de entrada e saída no Dynamo.

https://github.com/DynamoDS/Dynamo/wiki/Naming-Standards

Guia das Linguagens/APIs do Dynamo: a documentação das APIs do Dynamo atualmente cobre a funcionalidade principal

https://dynamods.github.io/DynamoAPI/

DynamoBIM: a melhor fonte para obter informações adicionais, conteúdo de aprendizagem e fóruns é o site do DynamoBIM.

https://dynamobim.org

Dicionário do Dynamo: um banco de dados pesquisável de todos os nós do Dynamo

https://dictionary.dynamobim.com/

Guia da Linguagem DesignScript: um guia em PDF para escrever em DesignScript

PDF

Como posso sugerir alterações a este guia?

Esta documentação está aberta a sugestões. Elas podem ser feitas diretamente no Github, criando solicitações de alterações.

Com um projeto do Visual Studio ativo e em execução, vamos analisar como compilar um nó personalizado que cria uma grade retangular de células. Embora possamos criar isso com vários nós padrão, é uma ferramenta útil que pode ser facilmente contida em um nó Sem toque. Ao contrário das linhas de grade, as células podem ser dimensionadas em torno de seus pontos centrais, consultadas para seus vértices de canto ou incorporadas em faces.

Este exemplo abordará alguns dos recursos e conceitos a serem considerados ao criar um nó Sem toque. Depois de compilarmos o nó personalizado e adicioná-lo ao Dynamo, verifique se a página “Aprofundar o conhecimento sobre o nó Sem Toque” fornece uma visão mais profunda dos valores de entrada padrão, retornando vários valores, documentação, objetos, usando tipos de geometria do Dynamo e migrações.

Nó de grade retangular personalizado

Para começar a compilar o nó de grade, crie um novo projeto de biblioteca de classes do Visual Studio. Consulte a página Introdução para obter uma visão geral detalhada de como configurar um projeto.

1. Escolher Class Library para o tipo de projeto

2. Nomear o projeto CustomNodes

Como vamos criar geometria, precisamos fazer referência ao pacote NuGet apropriado. Instale o pacote ZeroTouchLibrary do Gerenciador de pacotes Nuget. Esse pacote é necessário para a declaração using Autodesk.DesignScript.Geometry;.

1. Procure o pacote ZeroTouchLibrary

2. Usaremos esse nó na compilação atual do Dynamo Studio, que é 1.3. Selecione a versão do pacote que corresponde a isso.

3. Observe que também renomeamos o arquivo de classe para Grids.cs

Em seguida, precisamos estabelecer um namespace e uma classe na qual o método RetangularGrid residirá. O nó será nomeado no Dynamo de acordo com o método e os nomes de classe. Ainda não precisamos copiar isso no Visual Studio.

using Autodesk.DesignScript.Geometry;
using System.Collections.Generic;

namespace CustomNodes
{
    public class Grids
    {
        public static List<Rectangle> RectangularGrid(int xCount, int yCount)
        {
        //The method for creating a rectangular grid will live in here
        }
    }
}

Autodesk.DesignScript.Geometry; faz referência ao arquivo ProtoGeometry.dll no pacote ZeroTouchLibrary System.Collections.Generic, que é necessário para criar listas

Agora podemos adicionar o método para desenhar os retângulos. O arquivo de classe deve ter este aspecto e pode ser copiado para o Visual Studio.

using Autodesk.DesignScript.Geometry;
using System.Collections.Generic;

namespace CustomNodes
{
    public class Grids
    {
        public static List<Rectangle> RectangularGrid(int xCount, int yCount)
        {
            double x = 0;
            double y = 0;

            var pList = new List<Rectangle>();

            for (int i = 0; i < xCount; i++)
            {
                y++;
                x = 0;
                for (int j = 0; j < yCount; j++)
                {
                    x++;
                    Point pt = Point.ByCoordinates(x, y);
                    Vector vec = Vector.ZAxis();
                    Plane bP = Plane.ByOriginNormal(pt, vec);
                    Rectangle rect = Rectangle.ByWidthLength(bP, 1, 1);
                    pList.Add(rect);
                }
            }
            return pList;
        }
    }
}

Se o projeto for semelhante a este, vá em frente e tente compilar o .dll.

1. Escolher Compilar > Compilar solução

Verifique a pasta bin do projeto para obter um .dll. Se a compilação tiver sido bem-sucedida, poderemos adicionar o .dll ao Dynamo.

1. O nó personalizado RectangularGrids na Biblioteca do Dynamo

2. O nó personalizado na tela

3. O botão Adicionar para adicionar o .dll ao Dynamo

Modificações de nós personalizados

No exemplo acima, criamos um nó bastante simples que não definiu muito mais fora do método RectangularGrids. No entanto, podemos desejar criar dicas de ferramentas para portas de entrada ou fornecer ao nó um resumo, como os nós padrão do Dynamo. Adicionar esses recursos a nós personalizados facilita seu uso, especialmente se um usuário desejar pesquisá-los na biblioteca.

1. Um valor de entrada padrão

2. Uma dica de ferramenta para a entrada xCount

O nó RetangularGrid precisa de alguns desses recursos básicos. No código abaixo, adicionamos descrições de porta de entrada e saída, um resumo e valores de entrada padrão.

using Autodesk.DesignScript.Geometry;
using System.Collections.Generic;

namespace CustomNodes
{
    public class Grids
    {
        /// <summary>
        /// This method creates a rectangular grid from an X and Y count.
        /// </summary>
        /// <param name="xCount">Number of grid cells in the X direction</param>
        /// <param name="yCount">Number of grid cells in the Y direction</param>
        /// <returns>A list of rectangles</returns>
        /// <search>grid, rectangle</search>
        public static List<Rectangle> RectangularGrid(int xCount = 10, int yCount = 10)
        {
            double x = 0;
            double y = 0;

            var pList = new List<Rectangle>();

            for (int i = 0; i < xCount; i++)
            {
                y++;
                x = 0;
                for (int j = 0; j < yCount; j++)
                {
                    x++;
                    Point pt = Point.ByCoordinates(x, y);
                    Vector vec = Vector.ZAxis();
                    Plane bP = Plane.ByOriginNormal(pt, vec);
                    Rectangle rect = Rectangle.ByWidthLength(bP, 1, 1);
                    pList.Add(rect);
                    Point cPt = rect.Center();
                }
            }
            return pList;
        }
    }
}

• Forneça os valores padrão das entradas atribuindo valores aos parâmetros do método: RectangularGrid(int xCount = 10, int yCount = 10)

• Crie dicas de ferramentas de entrada e saída, palavras-chave de pesquisa e um resumo com a documentação XML precedida por ///.

Para adicionar dicas de ferramentas, precisamos de um arquivo xml no diretório do projeto. É possível gerar um .xml automaticamente pelo Visual Studio ativando a opção.

1. Ative o arquivo de documentação XML aqui e especifique um caminho de arquivo. Isso gera um arquivo XML.

E pronto. Criamos um novo nó com vários recursos padrão. O capítulo a seguir, “Noções básicas sobre o nó Sem toque”, entra em mais detalhes sobre o desenvolvimento do nó Sem toque e os problemas dos quais você deve estar ciente.

Com um entendimento de como criar um projeto Sem toque, podemos nos aprofundar nos detalhes específicos da criação de um nó ao navegar pelo exemplo ZeroTouchEssentials no Dynamo Github.

Muitos dos nós padrão do Dynamo são essencialmente nós Sem toque, como a maioria dos nós matemáticos, de cor e de data e hora acima.

Para iniciar, faça o download do projeto ZeroTouchEssentials aqui: https://github.com/DynamoDS/ZeroTouchEssentials

No Visual Studio, abra o arquivo de solução ZeroTouchEssentials.sln e compile a solução.

O arquivo ZeroTouchEssentials.cs contém todos os métodos que iremos importar para o Dynamo.

Abra o Dynamo e importe o ZeroTouchEssentials.dll para obter os nós que faremos referência nos exemplos a seguir.

Os exemplos de código são extraídos e geralmente coincidem com ZeroTouchEssentials.cs. A documentação XML foi removida para mantê-los concisos, e cada exemplo de código criará o nó na imagem acima dele.

Valores de entrada padrão

O Dynamo suporta a definição de valores padrão para portas de entrada em um nó. Esses valores padrão serão fornecidos ao nó se as portas não tiverem conexões. Os padrões são expressos usando o mecanismo C# de especificação de argumentos opcionais no Guia de programação C#. Os valores padrão são especificados da seguinte maneira:

• Defina os parâmetros do método para um valor padrão: inputNumber = 2.0

namespace ZeroTouchEssentials
{
    public class ZeroTouchEssentials
    {
        // Set the method parameter to a default value
        public static double MultiplyByTwo(double inputNumber = 2.0) 
        {
            return inputNumber * 2.0;
        }
    }
}

1. O valor padrão será exibido quando você passar o cursor sobre a porta de entrada do nó

Retornar vários valores

Retornar vários valores é um pouco mais complexo do que criar várias entradas e isso precisará ser feito usando um dicionário. As entradas do dicionário se tornam portas no lado de saída do nó. Várias portas de retorno são criadas da seguinte maneira:

• Adicione using System.Collections.Generic; para usar Dictionary<>.

• Adicione using Autodesk.DesignScript.Runtime; para usar o atributo MultiReturn. Isso faz referência ao “DynamoServices.dll” do pacote DynamoServices NuGet.

• Adicione o atributo [MultiReturn(new[] { "string1", "string2", ... more strings here })] ao método. As sequências de caracteres se referem às chaves no dicionário e se tornarão os nomes das portas de saída.

• Retorne um Dictionary<> da função com chaves que coincidem com os nomes de parâmetro no atributo: return new Dictionary<string, object>

using System.Collections.Generic;
using Autodesk.DesignScript.Runtime;

namespace ZeroTouchEssentials
{
    public class ZeroTouchEssentials
    {
        [MultiReturn(new[] { "add", "mult" })]
        public static Dictionary<string, object> ReturnMultiExample(double a, double b)
        {
            return new Dictionary<string, object>

                { "add", (a + b) },
                { "mult", (a * b) }
            };
        }
    }
}

Consulte este exemplo de código em ZeroTouchEssentials.cs

Um nó que retorna várias saídas.

1. Observe que agora há duas portas de saída nomeadas de acordo com as sequências que inserimos para as chaves do dicionário.

Documentação, dicas de ferramentas e pesquisa

É recomendável adicionar documentação aos nós do Dynamo que descrevam a função, as entradas, as saídas, os identificadores de pesquisa do nó etc. Isso é feito por meio de identificadores de documentação XML. A documentação XML é criada da seguinte maneira:

• Qualquer texto de comentário que é precedido por três barras inclinadas adiante é considerado como documentação

  • Por exemplo: /// Documentation text and XML goes here

• Após as três barras, crie identificadores XML acima dos métodos que o Dynamo lerá ao importar o .dll

  • Por exemplo: /// <summary>...</summary>

• Ative a documentação XML no Visual Studio selecionando Project > Project Properties > Build e verificando XML documentation file

1. O Visual Studio gerará um arquivo XML na localização especificada

Os tipos de identificadores são os seguintes:

• /// <summary>...</summary> é a documentação principal do nó e será exibida como uma dica de ferramenta sobre o nó na barra lateral esquerda de pesquisa

• /// <param name="inputName">...</param> criará a documentação para os parâmetros de entrada específicos

• /// <returns>...</returns> criará a documentação para um parâmetro de saída

• /// <returns name = "outputName">...</returns> criará a documentação para vários parâmetros de saída

• /// <search>...</search> corresponderá o nó aos resultados da pesquisa com base em uma lista separada por vírgulas. Por exemplo, se criarmos um nó que subdivide uma malha, poderemos desejar adicionar identificadores como “malha”, “subdivisão” e “catmull-Clark”.

A seguir está um nó de exemplo com descrições de entrada e saída, bem como um resumo que será exibido na biblioteca.

using Autodesk.DesignScript.Geometry;

namespace ZeroTouchEssentials
{
    public class ZeroTouchEssentials
    {
        /// <summary>
        /// This method demonstrates how to use a native geometry object from Dynamo
        /// in a custom method
        /// </summary>
        /// <param name="curve">Input Curve. This can be of any type deriving from Curve, such as NurbsCurve, Arc, Circle, etc</param>
        /// <returns>The twice the length of the Curve </returns>
        /// <search>example,curve</search>
        public static double DoubleLength(Curve curve)
        {
            return curve.Length * 2.0;
        }
    }
}

Consulte este exemplo de código em ZeroTouchEssentials.cs

Observe que o código para esse nó de exemplo contém:

1. Um resumo dos nós

2. Uma descrição de entrada

3. Uma descrição de saída

Objetos

O Dynamo não tem uma palavra-chave new, portanto, os objetos precisarão ser construídos usando métodos de construção estáticos. Os objetos são construídos da seguinte maneira:

• Tornar o construtor interno internal ZeroTouchEssentials(), a menos que seja necessário de outra forma

• Construir o objeto com um método estático como public static ZeroTouchEssentials ByTwoDoubles(a, b)

Observação: O Dynamo usa o prefixo “Por” para indicar que um método estático é um construtor e, embora seja opcional, usar “Por” ajudará a biblioteca a se ajustar melhor ao estilo existente do Dynamo.

namespace ZeroTouchEssentials
{
    public class ZeroTouchEssentials
    {
        private double _a;
        private double _b;

        // Make the constructor internal
        internal ZeroTouchEssentials(double a, double b)
        {
            _a = a;
            _b = b;
        }

        // The static method that Dynamo will convert into a Create node
        public static ZeroTouchEssentials ByTwoDoubles(double a, double b)
        {
            return new ZeroTouchEssentials(a, b);
        }
    }
}

Consulte este exemplo de código em ZeroTouchEssentials.cs

Após a importação do dll ZeroTouchEssentials, haverá um nó ZeroTouchEssentials na biblioteca. É possível criar esse objeto usando o nó ByTwoDoubles.

Usar tipos de geometria do Dynamo

As bibliotecas do Dynamo podem usar tipos de geometria nativos do Dynamo como entradas e criar uma nova geometria como saídas. Os tipos de geometria são criados da seguinte maneira:

• Referenciar “ProtoGeometry.dll” no projeto incluindo using Autodesk.DesignScript.Geometry; na parte superior do arquivo C# e adicionando o pacote NuGet da ZeroTouchLibrary ao projeto.

• Importante: Gerencie os recursos de geometria que não são retornados das funções. Consulte a seção Dispor/usar declarações abaixo.

Observação: Os objetos de geometria do Dynamo são usados como qualquer outro objeto passado para funções.

using Autodesk.DesignScript.Geometry;

namespace ZeroTouchEssentials
{
    public class ZeroTouchEssentials
    {
        // "Autodesk.DesignScript.Geometry.Curve" is specifying the type of geometry input, 
        // just as you would specify a double, string, or integer 
        public static double DoubleLength(Autodesk.DesignScript.Geometry.Curve curve)
        {
            return curve.Length * 2.0;
        }
    }
}

Consulte este exemplo de código em ZeroTouchEssentials.cs

Um nó que obtém o comprimento de uma curva e o duplica.

1. Esse nó aceita um tipo de geometria de curva como uma entrada.

Dispor/usar declarações

Os recursos de geometria que não são retornados de funções precisarão ser gerenciados manualmente, a não ser que você esteja usando o Dynamo versão 2.5 ou posterior. No Dynamo 2.5 e versões posteriores, os recursos de geometria são manipulados internamente pelo sistema. No entanto, talvez você ainda precise descartar a geometria manualmente se tiver um caso de uso complexo ou precisar reduzir a memória em um momento determinado. O mecanismo do Dynamo lidará com quaisquer recursos de geometria que são retornados de funções. Os recursos de geometria que não são retornados podem ser manipulados manualmente das seguintes maneiras:

• Com uma declaração de uso:

  Copy

  using (Point p1 = Point.ByCoordinates(0, 0, 0))
  {
    using (Point p2 = Point.ByCoordinates(10, 10, 0))
    {
        return Line.ByStartPointEndPoint(p1, p2);
    }
  }

  A declaração de uso está documentada aqui

  Consulte Melhorias na estabilidade da geometria do Dynamo para saber mais sobre os novos recursos de estabilidade introduzidos no Dynamo 2.5

• Com chamadas Dispor manuais:

  Copy

  Point p1 = Point.ByCoordinates(0, 0, 0);
  Point p2 = Point.ByCoordinates(10, 10, 0);
  Line l = Line.ByStartPointEndPoint(p1, p2);
  p1.Dispose();
  p2.Dispose();
  return l;

Migrações

Ao publicar uma versão mais recente de uma biblioteca, os nomes de nós podem ser alterados. As alterações de nome podem ser especificadas em um arquivo de migrações para que os gráficos criados em versões anteriores de uma biblioteca continuem a funcionar corretamente quando uma atualização é feita. As migrações são implementadas da seguinte maneira:

• Crie um arquivo .xml na mesma pasta que o .dll com o seguinte formato: “BaseDLLName”.Migrations.xml

• Em .xml, crie um único elemento <migrations>...</migrations>

• Dentro do elemento de migrações, crie os elementos <priorNameHint>...</priorNameHint> para cada alteração de nome

• Para cada alteração de nome, forneça um elemento <oldName>...</oldName> e <newName>...</newName>

1. Clicar com o botão direito do mouse e selecionar Add > New Item

2. Escolher XML File

3. Para este projeto, vamos nomear o arquivo de migrações ZeroTouchEssentials.Migrations.xml

Esse código de exemplo está informando ao Dynamo que qualquer nó denominado GetClosestPoint agora é nomeado ClosestPointTo.

<?xml version="1.0"?>
<migrations>
  <priorNameHint>
    <oldName>Autodesk.DesignScript.Geometry.Geometry.GetClosestPoint</oldName>
    <newName>Autodesk.DesignScript.Geometry.Geometry.ClosestPointTo</newName>
  </priorNameHint>
</migrations>

Consulte este exemplo de código em ProtoGeometry.Migrations.xml

Elementos genéricos

No momento, o recurso Sem toque não suporta o uso de elementos genéricos. Eles podem ser usados, mas não no código que é importado diretamente onde o tipo não está definido. Métodos, propriedades ou classes que são genéricos e não têm o conjunto de tipos não podem ser expostos.

No exemplo abaixo, um nó Sem toque do tipo T não será importado. Se o resto da biblioteca for importado para o Dynamo, haverá exceções de tipo ausentes.

public class SomeGenericClass<T>
{
    public SomeGenericClass()
    {
        Console.WriteLine(typeof(T).ToString());
    }  
}

O uso de um tipo genérico com o tipo definido neste exemplo será importado para o Dynamo.

public class SomeWrapper
{
    public object wrapped;
    public SomeWrapper(SomeGenericClass<double> someConstrainedType)
    {
        Console.WriteLine(this.wrapped.GetType().ToString());
    }
}

Introdução:

O Dynamo 2.0 é uma versão principal e algumas APIs foram alteradas ou removidas. Uma das maiores alterações que afetarão os autores de nó e pacote é a nossa mudança para um formato de arquivo JSON.

Em geral, os autores do nó Sem toque não terão muito trabalho a fazer para que os pacotes sejam executados na versão 2.0.

Os nós da interface do usuário e os nós que derivam diretamente do NodeModel exigirão mais trabalho para serem executados na versão 2.x.

Os autores da extensão também podem ter algumas alterações potenciais a serem feitas, dependendo de quanto das APIs principais do Dynamo eles usam em suas extensões.

Regras gerais de empacotamento:

• Não agrupe o Dynamo ou o Dynamo Revit .dlls com o pacote. Esses dlls já serão carregados pelo Dynamo. Se você agrupar uma versão diferente da que o usuário carregou _(ou seja, você distribui o dynamo core 1.3, mas o usuário está executando o pacote no dynamo 2.0) _, ocorrerão erros misteriosos de tempo de execução. Isso inclui dlls como DynamoCore.dll, DynamoServices.dll, DSCodeNodes.dll, ProtoGeometry.dll

• Não agrupe nem distribua o newtonsoft.json.net com o pacote se você puder evitá-lo. Esse dll também será carregado pelo Dynamo 2.x. O mesmo problema que acima pode ocorrer.

• Não agrupe nem distribua o CEFSharp com o pacote se você puder evitá-lo. Esse dll também será carregado pelo Dynamo 2.x. O mesmo problema que acima pode ocorrer.

• Em geral, evite compartilhar dependências com o Dynamo ou o Revit se precisar controlar a versão dessa dependência.

Problemas comuns:

1) Durante a abertura de um gráfico, alguns nós têm várias portas com o mesmo nome, mas o gráfico parecia correto ao salvar. Esse problema pode ter algumas causas.

A causa raiz comum é porque o nó foi criado usando um construtor que recriou as portas. Em vez disso, o construtor que carregou as portas deveria ter sido usado. Esses construtores são geralmente marcados [JsonConstructor]veja exemplos abaixo

Isso pode ocorrer porque:

• Não havia nenhum [JsonConstructor] correspondente ou ele não foi passado de Inports e Outports do .dyn JSON.

• Havia duas versões do JSON.net carregadas no mesmo processo ao mesmo tempo, causando falha de tempo de execução .net, de modo que o atributo [JsonConstructor] não podia ser usado corretamente para marcar o construtor.

• O DynamoServices.dll com uma versão diferente da versão atual do Dynamo foi fornecido com o pacote e está causando a falha do tempo de execução .net ao identificar o atributo [MultiReturn]; portanto, os nós Sem toque marcados com vários atributos não terão sido aplicados. Você pode descobrir que um nó retorna uma única saída de dicionário em vez de várias portas.

2) Os nós estão completamente ausentes ao carregar o gráfico com alguns erros no console.

• Isso pode ocorrer se a desserialização falhar por algum motivo. É uma boa prática serializar somente as propriedades que você precisa. Podemos usar [JsonIgnore] em propriedades complexas que não precisam ser carregadas ou salvas para serem ignoradas. Propriedades como function pointer, delegate, action, ou event etc. Elas não devem ser serializadas, pois normalmente falharão ao desserializar e causarão um erro de tempo de execução.

Atualização em profundidade:

Nós personalizados 1.3 -> 2.0

Organizar nós personalizados no arquivo librarie.js

Problemas conhecidos:

• Um nome de nó personalizado coincidente e um nome de categoria no mesmo nível no librarie.js causa um comportamento inesperado. QNTM-3653 – evite usar os mesmos nomes para a categoria e os nós.

• Os comentários serão transformados em comentários de bloco ao invés de comentários de linha.

• Nomes de tipo curto serão substituídos por nomes completos. Por exemplo, se você não especificou um tipo ao carregar o nó personalizado novamente, verá var[]..[] – pois esse é o tipo padrão.

Nós Sem toque 1.3 -> 2.0

• No Dynamo 2.0, os tipos Lista e Dicionário foram divididos e a sintaxe para a criação de listas e dicionários foi alterada. As listas são inicializadas usando [], enquanto os dicionários usam {}. Se você estava usando o atributo DefaultArgument anteriormente para marcar parâmetros nos nós sem toque e usou a sintaxe da lista para padronizar para uma lista específica como someFunc([DefaultArgument("{0,1,2}")]), isso não será mais válido e será necessário modificar o fragmento DesignScript para usar a nova sintaxe de inicialização das listas.

• Como observado acima, não distribua os dlls do Dynamo com os pacotes. (DynamoCore, DynamoServices etc.)

Nós do modelo de nós 1.3 -> 2.0

Os nós do modelo de nós são os que requerem mais trabalho para serem atualizados para o Dynamo 2.x. Em um nível alto, será necessário implementar construtores que serão usados somente para carregar os nós do json, além dos construtores nodeModel normais que são usados para instanciar novas instâncias dos tipos de nó. Para diferenciar entre esses, marque os construtores de tempo de carga com [JsonConstructor], que é um atributo de newtonsoft.Json.net.

Os nomes dos parâmetros no construtor devem normalmente coincidir com os nomes das propriedades JSON – embora esse mapeamento se torne mais complicado se você substituir os nomes que são serializados usando os atributos [JsonProperty]. Consulte a documentação do Json.net para obter mais informações.

Construtores JSON

A alteração mais comum necessária para atualizar nós derivados da classe base NodeModel (ou outras classes base do núcleo do Dynamo, ou seja, DSDropDownBase) é a necessidade de adicionar um construtor JSON à classe.

O construtor original sem parâmetros ainda lidará com a inicialização de um novo nó que é criado no Dynamo (por exemplo, através da biblioteca). O construtor JSON é necessário para inicializar um nó que é desserializado (carregado) de um arquivo .dyn ou .dyf salvo.

O construtor JSON difere do construtor base no fato de ter parâmetros PortModel para inPorts e outPorts, que são fornecidos pela lógica de carregamento JSON. A chamada para registrar as portas para o nó não é necessária aqui, pois os dados existem no arquivo .dyn. Um exemplo de construtor JSON se parece com isto:

using Newtonsoft.Json; //New dependency for Json

………

[JsonConstructor] //Attribute required to identity the Json constructor

//Minimum constructor implementation. Note that the base method invocation must also be present.

FooNode(IEnumerable<PortModel> inPorts, IEnumerable<PortModel> outPorts) : base(inPorts, outPorts) { }

Esta sintaxe :base(Inports,outPorts){} chama o construtor base nodeModel e passa as portas desserializadas para ele.

Qualquer lógica especial que existisse no construtor de classe que envolva a inicialização de dados específicos que são serializados no arquivo .dyn (por exemplo, definir o registro de porta, estratégia de amarra, etc) não precisa ser repetida nesse construtor, pois esses valores podem ser lidos do JSON.

Essa é a principal diferença entre o construtor JSON e os construtores não JSON para os nodeModels. Os construtores JSON são chamados ao carregar de um arquivo e são passados os dados carregados. No entanto, outra lógica do usuário deve ser duplicada no construtor JSON (por exemplo, inicializando manipuladores de eventos para o nó ou anexando).

Exemplos podem ser encontrados aqui no repositório do DynamoSamples -> ButtonCustomNodeModel, DropDown ou SliderCustomNodeModel

Propriedades públicas e serialização

Anteriormente, um desenvolvedor podia serializar e desserializar dados de modelo específicos para o documento xml usando os métodos SerializeCore e DeserializeCore. Esses métodos ainda existem na API, mas serão obsoletos em uma versão futura do Dynamo (um exemplo pode ser encontrado aqui). Com a implementação do JSON.NET, agora as propriedades public na classe derivada NodeModel podem ser serializadas diretamente para o arquivo .dyn. O JSON.Net fornece vários atributos para controlar como a propriedade é serializada.

Esse exemplo que especifica um PropertyName é encontrado aqui no repositório do Dynamo.

[JsonProperty(PropertyName = "InputValue")]

public DSColor DsColor {...

Conversores:

Observação Se você criar sua própria classe de conversor JSON.net, o Dynamo não terá um mecanismo que permita injetá-la nos métodos de carregamento e salvamento e, portanto, mesmo que você marque a classe com o atributo [JsonConverter], ela poderá não ser usada. Em vez disso, você poderá chamar o conversor diretamente no configurador ou getter. //TODO precisa de confirmação dessa limitação. Qualquer evidência é bem-vinda.

Um exemplo que especifica um método de serialização para converter a propriedade em uma sequência de caracteres é encontrado aqui no repositório do Dynamo.

[JsonProperty("MeasurementType"), JsonConverter(typeof(StringEnumConverter))]

public ConversionMetricUnit SelectedMetricConversion{...

Ignorar as propriedades

As propriedades public que não são destinadas à serialização precisam ter o atributo [JsonIgnore] adicionado. Quando os nós são salvos no arquivo .dyn, isso garante que esses dados sejam ignorados pelo mecanismo de serialização e não causará consequências inesperadas quando o gráfico for aberto novamente. Um exemplo disso pode ser encontrado aqui no repositório do Dynamo.

Desfazer/Refazer

Como mencionado acima, os métodos SerializeCore e DeserializeCore foram usados no passado para salvar e carregar nós no arquivo xml .dyn. Além disso, eles também foram usados para salvar e carregar o estado do nó para desfazer/refazer e ainda são. Se você desejar implementar a funcionalidade desfazer/refazer complexa para o nó da interface do usuário nodeModel, será necessário implementar esses métodos e serializar no objeto de documento XML fornecido como um parâmetro para esses métodos. Esse deve ser um caso de uso raro, exceto para nós de interface do usuário complexos.

APIs de porta de entrada e saída

Uma ocorrência comum nos nós nodeModel afetados pelas alterações da API 2.0 é o registro de porta no construtor do nó. Observando exemplos no repositório do Dynamo ou DynamoSamples, você terá encontrado o uso dos métodos InPortData.Add() ou OutPortData.Add(). Anteriormente, na API do Dynamo, as propriedades InPortData e OutPortData públicas eram marcadas como obsoletas. Na versão 2.0, essas propriedades foram removidas. Os desenvolvedores agora devem usar os métodos InPorts.Add() e OutPorts.Add(). Além disso, esses dois métodos Add() têm assinaturas ligeiramente diferentes:

InPortData.Add(new PortData("Port Name", "Port Description")); //Old version valid in 1.3 but now deprecated

x

InPorts.Add(new PortModel(PortType.Input, this, new PortData("Port Name", "Port Description"))); //Recommended 2.0

Exemplos de código convertido podem ser encontrados aqui no repositório do Dynamo -> DynamoConvert.cs ou FileSystem.cs

O outro caso de uso comum afetado pelas alterações da API 2.0 se relaciona aos métodos comumente usados no método BuildAst() para determinar o comportamento do nó com base na presença ou ausência de conectores de porta. Anteriormente, HasConnectedInput(index) era usado para validar um estado de porta conectada. Os desenvolvedores agora devem usar a propriedade InPorts[0].IsConnected para verificar o estado de conexão da porta. Um exemplo desse ícone pode ser encontrado em ColorRange.cs no repositório do Dynamo.

Exemplos:

Vamos passar pela atualização de um nó de interface do usuário 1.3 para o Dynamo 2.x.

using System;
using System.Collections.Generic;
using Dynamo.Graph.Nodes;
using CustomNodeModel.CustomNodeModelFunction;
using ProtoCore.AST.AssociativeAST;
using Autodesk.DesignScript.Geometry;

namespace CustomNodeModel.CustomNodeModel
{
    [NodeName("RectangularGrid")]
    [NodeDescription("An example NodeModel node that creates a rectangular grid. The slider randomly scales the cells.")]
    [NodeCategory("CustomNodeModel")]
    [InPortNames("xCount", "yCount")]
    [InPortTypes("double", "double")]
    [InPortDescriptions("Number of cells in the X direction", "Number of cells in the Y direction")]
    [OutPortNames("Rectangles")]
    [OutPortTypes("Autodesk.DesignScript.Geometry.Rectangle[]")]
    [OutPortDescriptions("A list of rectangles")]
    [IsDesignScriptCompatible]
    public class GridNodeModel : NodeModel
    {
        private double _sliderValue;
        public double SliderValue
        {
            get { return _sliderValue; }
            set
            {
                _sliderValue = value;
                RaisePropertyChanged("SliderValue");
                OnNodeModified(false);
            }
        }
        public GridNodeModel()
        {
            RegisterAllPorts();
        }
        public override IEnumerable<AssociativeNode> BuildOutputAst(List<AssociativeNode> inputAstNodes)
        {
            if (!HasConnectedInput(0) || !HasConnectedInput(1))
            {
                return new[] { AstFactory.BuildAssignment(GetAstIdentifierForOutputIndex(0), AstFactory.BuildNullNode()) };
            }
            var sliderValue = AstFactory.BuildDoubleNode(SliderValue);
            var functionCall =
              AstFactory.BuildFunctionCall(
                new Func<int, int, double, List<Rectangle>>(GridFunction.RectangularGrid),
                new List<AssociativeNode> { inputAstNodes[0], inputAstNodes[1], sliderValue });

            return new[] { AstFactory.BuildAssignment(GetAstIdentifierForOutputIndex(0), functionCall) };
        }
    }
}

Tudo o que precisamos fazer para esta classe nodeModel para que ela seja carregada e salva corretamente na versão 2.0 é adicionar um jsonConstructor para lidar com o carregamento das portas. Simplesmente passamos as portas no construtor base e essa implementação fica vazia.

[JsonConstructor]
protected GridNodeModel(IEnumerable<PortModel> Inports, IEnumerable<PortModel> Outports ) :
base(Inports,Outports)
{

}

Observação: Não chame RegisterPorts() ou alguma variação disso no JsonConstructor. Isso usará os atributos de parâmetro de entrada e saída na classe de nó para construir novas portas. Não queremos isso, pois queremos usar as portas carregadas que são passadas para o construtor.

[InPortNames("xCount", "yCount")]
[InPortTypes("double", "double")]

Este exemplo adiciona o construtor JSON de carga mínima possível. Mas e se precisarmos fazer uma lógica de construção mais complexa, como configurar alguns ouvintes para manipulação de eventos dentro do construtor? A próxima amostra obtida do Repositório do DynamoSamples está vinculada acima na JsonConstructors Section deste documento.

Aqui está um construtor mais complexo para um nó de interface do usuário:

 public ButtonCustomNodeModel()
        {
            // When you create a UI node, you need to do the
            // work of setting up the ports yourself. To do this,
            // you can populate the InPorts and the OutPorts
            // collections with PortData objects describing your ports.
            InPorts.Add(new PortModel(PortType.Input, this, new PortData("inputString", "a string value displayed on our button")));

            // Nodes can have an arbitrary number of inputs and outputs.
            // If you want more ports, just create more PortData objects.
            OutPorts.Add(new PortModel(PortType.Output, this, new PortData("button value", "returns the string value displayed on our button")));
            OutPorts.Add(new PortModel(PortType.Output, this, new PortData("window value", "returns the string value displayed in our window when button is pressed")));

            // This call is required to ensure that your ports are
            // properly created.
            RegisterAllPorts();

            // Listen for input port disconnection to trigger button UI update
            this.PortDisconnected += ButtonCustomNodeModel_PortDisconnected;

            // The arugment lacing is the way in which Dynamo handles
            // inputs of lists. If you don't want your node to
            // support argument lacing, you can set this to LacingStrategy.Disabled.
            ArgumentLacing = LacingStrategy.Disabled;

            // We create a DelegateCommand object which will be 
            // bound to our button in our custom UI. Clicking the button 
            // will call the ShowMessage method.
            ButtonCommand = new DelegateCommand(ShowMessage, CanShowMessage);

            // Setting our property here will trigger a 
            // property change notification and the UI 
            // will be updated to reflect the new value.
            ButtonText = defaultButtonText;
            WindowText = defaultWindowText;
        }

Quando adicionamos um construtor JSON para carregar esse nó de um arquivo, precisamos recriar parte dessa lógica, mas observe que não incluímos o código que cria portas, que define amarra ou que define os valores padrão para propriedades que podemos carregar do arquivo.

        // This constructor is called when opening a Json graph.

        [JsonConstructor]
        ButtonCustomNodeModel(IEnumerable<PortModel> inPorts, IEnumerable<PortModel> outPorts) : base(inPorts, outPorts)
        {
            this.PortDisconnected += ButtonCustomNodeModel_PortDisconnected;
            ButtonCommand = new DelegateCommand(ShowMessage, CanShowMessage);
        }

Observe que outras propriedades públicas que foram serializadas no JSON como ButtonText e WindowText não serão adicionadas como parâmetros explícitos ao construtor – elas são definidas automaticamente pelo JSON.net usando os definidores para essas propriedades.

Se você estiver desenvolvendo montagens a serem publicadas como um pacote do Dynamo, o projeto poderá ser configurado para agrupar todos os recursos necessários e colocá-los em uma estrutura de diretório compatível com o pacote. Isso permitirá que o projeto seja rapidamente testado como um pacote e simulará a experiência do usuário.

Como compilar diretamente na pasta de pacotes

Há dois métodos para compilar um pacote no Visual Studio:

• Adicionar eventos pós-compilação através da caixa de diálogo Configurações do projeto que usam scripts xcopy ou Python para copiar os arquivos necessários

• Usar o destino de compilação “AfterBuild” no arquivo .csproj para criar tarefas de cópia de arquivos e diretórios

“AfterBuild” é o método preferido para esses tipos de operações (e o que é abordado neste guia), pois não depende da cópia de arquivos que podem não estar disponíveis no computador de compilação.

Copiar arquivos de pacote com o método AfterBuild

Configure a estrutura de diretórios no repositório para que os arquivos de origem sejam separados dos arquivos de pacote. Trabalhando com o estudo de caso CustomNodeModel, coloque o projeto do Visual Studio e todos os arquivos associados em uma nova pasta src. Todos os pacotes gerados pelo projeto serão armazenados nessa pasta. A estrutura de pastas deve ter este aspecto:

CustomNodeModel
> src
  > CustomNodeModel
  > CustomNodeModelFunction
  > packages
  > CustomNodeModel.sln

1. Mover os arquivos de projeto para a nova pasta src

Agora que os arquivos de origem estão em uma pasta separada, adicione um destino AfterBuild ao arquivo CustomNodeModel.csproj no Visual Studio. Isso deve copiar os arquivos necessários para uma nova pasta de pacote. Abra o arquivo CustomNodeModel.csproj em um editor de texto (usamos o Atom) e coloque o destino da compilação antes do identificador de fechamento </Project>. Esse destino AfterBuild copiará todos os arquivos .dll, .pbd, .xml e .config para uma nova pasta bin e criará as pastas dyf e extras.

  <Target Name="AfterBuild">
    <ItemGroup>
      <Dlls Include="$(OutDir)*.dll" />
      <Pdbs Include="$(OutDir)*.pdb" />
      <Xmls Include="$(OutDir)*.xml" />
      <Configs Include="$(OutDir)*.config" />
    </ItemGroup>
    <Copy SourceFiles="@(Dlls)" DestinationFolder="$(SolutionDir)..\packages\CustomNodeModel\bin\" />
    <Copy SourceFiles="@(Pdbs)" DestinationFolder="$(SolutionDir)..\packages\CustomNodeModel\bin\" />
    <Copy SourceFiles="@(Xmls)" DestinationFolder="$(SolutionDir)..\packages\CustomNodeModel\bin\" />
    <Copy SourceFiles="@(Configs)" DestinationFolder="$(SolutionDir)..\packages\CustomNodeModel\bin\" />
    <MakeDir Directories="$(SolutionDir)..\packages\CustomNodeModel\dyf" />
    <MakeDir Directories="$(SolutionDir)..\packages\CustomNodeModel\extra" />
  </Target>

Precisamos ter certeza de que o destino foi adicionado ao arquivo CustomNodeModel.csproj (não a outro arquivo de projeto) e que o projeto não tem nenhuma configuração Pós-compilação existente.

1. Colocar o destino AfterBuild antes do identificador </Project> final.

Na seção <ItemGroup>, são definidas um número de variáveis para representar tipos de arquivo específicos. Por exemplo, a variável Dll representa todos os arquivos no diretório de saída cuja extensão é .dll.

<ItemGroup>
  <Dlls Include="$(OutDir)*.dll" />
</ItemGroup>

O objetivo da tarefa Copy é copiar todos os arquivos .dll para um diretório, especificamente a pasta de pacotes para a qual estamos compilando.

<Copy SourceFiles="@(Dlls)" DestinationFolder="$(SolutionDir)..\packages\CustomNodeModel\bin\" />

Os pacotes do Dynamo normalmente têm uma pasta dyf e extra para os nós personalizados do Dynamo e outros recursos, como imagens. Para criar essas pastas, é preciso usar uma tarefa MakeDir. Essa tarefa criará uma pasta se ela não existir. É possível adicionar arquivos manualmente a essa pasta.

<MakeDir Directories="$(SolutionDir)..\packages\CustomNodeModel\extra" />

Se você compilar o projeto, a pasta do projeto agora deverá ter uma pasta packages junto com a pasta src criada anteriormente. Dentro do diretório packages, há uma pasta que contém tudo o que é necessário para o pacote. Também precisamos copiar o arquivo pkg.json para a pasta do pacote para que o Dynamo saiba como carregar o pacote.

1. A nova pasta de pacotes que o destino AfterBuild criou

2. A pasta src existente com o projeto

3. As pastas dyf e extra criadas no destino AfterBuild

4. Copiar manualmente o arquivo pkg.json.

Agora você pode publicar o pacote usando o gerenciador de pacotes do Dynamo ou copiá-lo diretamente para o diretório de pacotes do Dynamo: <user>\AppData\Roaming\Dynamo\1.3\packages.

Publicar um pacote

Os pacotes são uma forma conveniente de armazenar e compartilhar nós com a comunidade do Dynamo. Um pacote pode conter tudo, desde nós personalizados criados no espaço de trabalho do Dynamo até nós derivados do NodeModel. Os pacotes são publicados e instalados usando o Gerenciador de pacotes. Além desta página, o Manual tem um guia geral sobre os pacotes.

O que é um Gerenciador de pacotes?

O Gerenciador de pacotes do Dynamo é um Registro de software (semelhante ao npm) que pode ser acessado no Dynamo ou em um navegador da Web. O Gerenciador de pacotes inclui a instalação, publicação, atualização e visualização de pacotes. Como o npm, ele mantém diferentes versões de pacotes. Também ajuda a gerenciar as dependências do projeto.

No navegador, procure pacotes e visualize as estatísticas: https://dynamopackages.com/

• No Dynamo, o Gerenciador de pacotes inclui pacotes de instalação, publicação e atualização.

1. Procurar pacotes on-line: Packages > Search for a Package...

2. Visualizar/editar pacotes instalados: Packages > Manage Packages...

3. Publicar um novo pacote: Packages > Publish New Package...

Publicar um pacote

Os pacotes são publicados do Gerenciador de pacotes no Dynamo. O processo recomendado é publicar localmente, testar o pacote e, em seguida, publicar on-line para compartilhar com a comunidade. Usando o estudo de caso NodeModel, vamos passar pelas etapas necessárias para publicar o nó RetangularGrid como um pacote localmente e, em seguida, on-line.

Inicie o Dynamo e selecione Packages > Publish New Package... para abrir a janela Publish a Package.

1. Selecionar Add file... para procurar arquivos para adicionar ao pacote

2. Selecionar os dois arquivos .dll no estudo de caso NodeModel

3. Selecionar Ok

Com os arquivos adicionados ao conteúdo do pacote, atribua um nome, uma descrição e uma versão ao pacote. A publicação de um pacote usando o Dynamo cria automaticamente um arquivo pkg.json.

Um pacote pronto para ser publicado.

1. Fornecer as informações necessárias para o nome, a descrição e a versão.

2. Publicar clicando em “Publicar localmente” e selecionar a pasta de pacotes do Dynamo: AppData\Roaming\Dynamo\Dynamo Core\1.3\packages para ter o nó disponível no Core. Sempre publique localmente até que o pacote esteja pronto para compartilhar.

Após a publicação de um pacote, os nós estarão disponíveis na biblioteca do Dynamo na categoria CustomNodeModel.

1. O pacote que acabamos de criar na biblioteca do Dynamo

Quando o pacote estiver pronto para publicação on-line, abra o Gerenciador de pacotes, escolha Publish e, em seguida, Publish Online.

1. Para ver como o Dynamo formatou o pacote, clicar nos três pontos verticais à direita de “CustomNodeModel” e escolher “Mostrar diretório raiz”

2. Selecionar Publish e, em seguida, Publish Online na janela “Publicar um pacote do Dynamo”.

3. Para excluir um pacote, selecionar Delete.

Como atualizar um pacote?

A atualização de um pacote é um processo semelhante ao da publicação. Abra o Gerenciador de pacotes e selecione Publish Version... no pacote que precisa ser atualizado e insira uma versão posterior.

1. Selecionar Publish Version para atualizar um pacote existente com novos arquivos no diretório raiz e, em seguida, escolher se ele deve ser publicado localmente ou on-line.

Cliente Web do Gerenciador de pacotes

O cliente Web do Gerenciador de pacotes é usado exclusivamente para pesquisar e visualizar dados de pacotes, como o controle de versão e estatísticas de download.

É possível acessar o cliente Web do Gerenciador de pacotes neste link: https://dynamopackages.com/

Os arquivos de origem do DynamoRevit também estão hospedados no DynamoDS Github para que os desenvolvedores façam contribuições e compilem versões beta. A compilação do DynamoRevit da origem geralmente segue o mesmo processo que o Dynamo, com exceção de alguns detalhes importantes:

• O DynamoRevit faz referência a montagens do Dynamo, portanto, elas devem ser compiladas com pacotes NuGet correspondentes. Por exemplo, o DynamoRevit 2.x não será carregado no Dynamo 1.3.

• O DynamoRevit é específico para as versões do Revit, por exemplo: a ramificação do DynamoRevit 2018 deve ser executada no Revit 2018.

Para este guia, usaremos o seguinte:

• Revit 2023

• A compilação mais recente do DynamoRevit compilada na ramificação Revit2023

• A compilação mais recente do Dynamo

Para garantir uma compilação bem-sucedida, clonaremos e compilaremos os repositórios do Dynamo e do DynamoRevit para usar nesta apresentação.

Observação: A compilação manual do Dynamo antes do DynamoRevit só será necessária se você estiver compilando o Dynamo 1.x e o DynamoRevit 1.x – as versões mais recentes do repositório do DynamoRevit dependem do gerenciador de pacotes do NuGet para as dependências do Dynamo necessárias para a compilação. Embora uma compilação do DynamoRevit 2.x não exija a extração manual do Dynamo, você ainda precisará dos dlls principais em outro lugar para realmente executar o addin do DynamoRevit. Portanto, vale a pena extrair e compilar o Dynamo. Veja mais abaixo: Compilar o repositório usando o Visual Studio

Localização do repositório do DynamoRevit no Github

O código do projeto DynamoRevit reside em um repositório separado no Github do código-fonte do Dynamo principal. Esse repositório contém os arquivos de origem para nós específicos do Revit e o complemento do Revit que carrega o Dynamo. As compilações do DynamoRevit para diferentes versões do Revit (2016, 2017 ou 2018, por exemplo) são organizadas como ramificações no repositório.

A origem do DynamoRevit está hospedada aqui: https://github.com/DynamoDS/DynamoRevit

1. Clonar ou fazer download do repositório

2. As ramificações do DynamoRevit fazem referência a versões do Revit

Clonar o repositório usando o git

Em um processo semelhante ao da extração do repositório do Dynamo, usaremos o comando git clone para clonar o DynamoRevit e especificaremos a ramificação que corresponde à nossa versão do Revit. Para começar, abriremos uma interface de linha de comando e definiremos o diretório atual para o local onde desejamos clonar os arquivos.

cd C:\Users\username\Documents\GitHub altera o diretório atual

Substitua username por seu nome de usuário

Agora podemos clonar o repositório para esse diretório. Embora precisemos especificar uma ramificação do repositório, podemos alternar para essa ramificação após a clonagem.

git clone https://github.com/DynamoDS/DynamoRevit.git clona o repositório de um URL remoto e, por padrão, alterna para a ramificação mestre.

Quando o repositório tiver terminado a clonagem, altere o diretório atual para a pasta do repositório e alterne para a ramificação que corresponde à versão instalada do Revit. Neste exemplo, estamos usando o Revit RC2.13.1_Revit2023. Todas as ramificações remotas podem ser visualizadas na página do Github no menu suspenso Ramificações.

cd C:\Users\username\Documents\GitHub\DynamoRevit altera o diretório para DynamoRevit. git checkout RC2.13.1_Revit2023 define a ramificação atual como RC2.13.1_Revit2023. git branch verifica em qual ramificação estamos e mostra as outras que existem localmente.

A ramificação com um asterisco é a que está atualmente verificada. A ramificação Revit2018 é exibida porque já foi verificada anteriormente e, portanto, ela existe localmente.

É importante escolher a ramificação correta do repositório para assegurar que, quando o projeto for compilado no Visual Studio, ele fará referência a montagens na versão correta do diretório de instalação do Revit, especificamente RevitAPI.dll e RevitAPIUI.dll.

Compilar o repositório usando o Visual Studio

Antes de compilar o repositório, precisaremos restaurar os pacotes NuGet com o arquivo restorepackages.bat localizado na pasta src. Esse arquivo bat usa o gerenciador de pacotes nuget para extrair os binários compilados do dynamo core, necessários para o DynamoRevit. Você também pode optar por compilá-los manualmente, mas se somente estiver fazendo alterações no DynamoRevit e não no núcleo do Dynamo. Isso torna mais rápido começar. Certifique-se de executar esse arquivo como administrador.

1. Clicar com o botão direito do mouse em restorepackages.bat e selecione Run as administrator

Se os pacotes forem restaurados com êxito, uma pasta packages será adicionada à pasta src com os pacotes beta NuGet mais recentes.

1. Os pacotes beta mais recentes do Dynamo NuGet

Com os pacotes restaurados, abra o arquivo de solução DynamoRevit.All.sln do Visual Studio em src e compile a solução. A compilação pode ter problemas para encontrar AssemblySharedInfo.cs inicialmente. Se isso acontecer, a nova execução da compilação resolverá esse problema.

1. Selecionar Build > Build Solution

2. Verificar se a compilação foi bem-sucedida na janela Saída. A mensagem deve ser ===== Build: 13 succeeded, 0 failed, 0 up-to-date, 0 skipped =====.

Executar uma compilação local do DynamoRevit no Revit

O Revit requer um arquivo de complemento para reconhecer o DynamoRevit, algo que o instalador criaria automaticamente. Durante o desenvolvimento, precisamos criar manualmente um arquivo de complemento que aponte para a compilação do DynamoRevit que desejamos usar, especificamente a montagem DynamoRevitDS.dll. Também precisamos apontar o DynamoRevit para uma compilação do Dynamo.

Crie um arquivo Dynamo.addin na pasta de complementos do Revit localizada em C:\ProgramData\Autodesk\Revit\Addins\2023. Já tínhamos uma versão do DynamoRevit instalada, portanto, vamos apenas editar o arquivo existente para apontar para a nova compilação.

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<RevitAddIns>
<AddIn Type="Application">
<Name>Dynamo For Revit</Name>
<Assembly>"C:\Users\username\Documents\GitHub\DynamoRevit\bin\AnyCPU\Debug\Revit\DynamoRevitDS.dll"</Assembly>
<AddInId>8D83C886-B739-4ACD-A9DB-1BC78F315B2B</AddInId>
<FullClassName>Dynamo.Applications.DynamoRevitApp</FullClassName>
<VendorId>ADSK</VendorId>
<VendorDescription>Dynamo</VendorDescription>
</AddIn>
</RevitAddIns>

• Especificar o caminho do arquivo de DynamoRevitDS.dll dentro de <Assembly>...</Assembly>.

Como alternativa, podemos fazer com que o complemento carregue o seletor de versão em vez de uma montagem específica.

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<RevitAddIns>
<AddIn Type="Application">
<Name>Dynamo For Revit</Name>
<Assembly>"C:\Users\username\Documents\GitHub\DynamoRevit\bin\AnyCPU\Debug\Revit\DynamoRevitVersionSelector.dll"</Assembly>
<AddInId>8D83C886-B739-4ACD-A9DB-1BC78F315B2B</AddInId>
<FullClassName>Dynamo.Applications.VersionLoader</FullClassName>
<VendorId>ADSK</VendorId>
<VendorDescription>Dynamo</VendorDescription>
</AddIn>
</RevitAddIns>

• Definir o caminho do arquivo <Assembly>...</Assembly> como DynamoRevitVersionSelector.dll

• <FullClassName>...</FullClassName> especifica a classe a ser instanciada da montagem que apontamos com o caminho do elemento de montagem acima. Essa classe será o ponto de entrada de nosso complemento.

Além disso, precisamos remover o Dynamo existente que é fornecido com o Revit. Para fazer isso, vá para C:\\Program Files\Autodesk\Revit 2023\AddIns e remova as duas pastas que contêm o Dynamo – DynamoForRevit e DynamoPlayerForRevit. Será possível excluí-los ou fazer backup deles em uma pasta separada se for necessário recuperar o Dynamo for Revit original.

A segunda etapa é adicionar um caminho de arquivo para as montagens principais do Dynamo ao arquivo Dynamo.config na pasta bin do DynamoRevit. O DynamoRevit carregará essas montagens quando o complemento for aberto no Revit. Esse arquivo de configuração permite apontar o complemento do DynamoRevit para diferentes versões do núcleo do Dynamo para desenvolver e testar as alterações no núcleo e no DynamoRevit.

O código deve se parecer com o seguinte:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <appSettings>
     <add key="DynamoRuntime" value="C:\Users\username\Documents\GitHub\Dynamo\bin\AnyCPU\Debug"/>
  </appSettings>
</configuration>

• Adicionar o caminho do diretório da pasta bin a <add key/>

Clonamos e compilamos o Dynamo logo antes dessa apresentação para garantir que ele funcionará bem com o DynamoRevit. O caminho do diretório aponta para essa compilação.

Agora, quando abrimos o Revit, deverá haver um complemento do Dynamo localizado na guia Gerenciar.

1. Selecionar Manage

2. Clicar no ícone do complemento do Dynamo

3. Uma instância do DynamoRevit

Se uma janela de caixa de diálogo de erro aparecer mostrando montagens ausentes, é provável que tenha havido uma incompatibilidade entre as versões do DynamoCore compiladas e as que estão sendo carregadas no tempo de execução. Por exemplo, o DynamoRevit com os pacotes beta 2.0 mais recentes do DynamoCore não funcionará se você tentar iniciá-lo usando os dlls do Dynamo 1.3. Assegure-se de que ambos os repositórios sejam da mesma versão e que o DynamoRevit esteja extraindo uma versão correspondente das dependências nuget. Essas são definidas no arquivo package.json do repositório do DynamoRevit.

Depurar o DynamoRevit usando o Visual Studio

Na seção anterior, Compilar o Dynamo da origem, apresentamos brevemente a depuração no Visual Studio e como anexar o Visual Studio a um processo. Usando uma exceção no nó Wall.ByCurveAndHeight como exemplo, vamos analisar como anexar a um processo, definir pontos de quebra, passar pelo código e usar a pilha de chamadas para determinar a origem da exceção. Essas ferramentas de depuração geralmente se aplicam aos fluxos de trabalho de desenvolvimento do .net e vale a pena explorá-los fora deste guia.

• Anexar ao processo vincula um aplicativo em execução ao Visual Studio para depuração. Se quisermos depurar o comportamento que ocorre em uma compilação do DynamoRevit, poderemos abrir os arquivos de origem do DynamoRevit no Visual Studio e anexar o processo Revit.exe, que é o processo principal do complemento DynamoRevit. O Visual Studio usa um arquivo de símbolo (.pbd) para fazer a conexão entre as montagens que o DynamoRevit está executando e o código-fonte.

• Pontos de quebra: estabelecem linhas no código-fonte onde o aplicativo pausará antes da execução. Se um nó estiver causando um erro fatal do DynamoRevit ou retornar um resultado inesperado, poderemos adicionar um ponto de quebra à origem do nó para pausar o processo, entrar no código e inspecionar os valores ao vivo das variáveis até que encontremos a causa do problema

• Passar pelo código explica a origem, linha por linha. Podemos executar funções uma a uma, entrar em uma chamada de função ou sair da função que estamos executando no momento.

• A pilha de chamadas mostra a função que um processo está executando no momento em relação às chamadas de função anteriores que invocaram essa chamada de função. O Visual Studio tem uma janela Pilha de chamadas para exibir isso. Por exemplo, se ocorrer uma exceção fora do código-fonte, poderemos ver o caminho para o código de chamada na pilha de chamadas.

  2,000 Things You Should Know About C# (2.000 coisas que você deve saber sobre C#) têm uma explicação mais detalhada das pilhas de chamadas

O nó Wall.ByCurveAndHeight gera uma exceção quando recebe uma PolyCurve como sua entrada de curva com a mensagem: “Para BSPlineCurve não implementado”. Com a depuração, podemos descobrir por que exatamente o nó não aceitará esse tipo de geometria como uma entrada para o parâmetro de curva. Neste exemplo, estamos assumindo que o DynamoRevit foi criado com êxito e pode ser executado como um complemento do Revit.

1. O nó Wall.ByCurveAndHeight está gerando uma exceção

Comece abrindo o arquivo de solução DynamoRevit.All.sln, inicie o Revit e inicie o complemento DynamoRevit. Em seguida, anexe o Visual Studio ao processo do Revit com a janela Attach to Process.

O Revit e o Dynamo Revit precisam estar em execução para serem exibidos como um processo disponível

1. Abrir a janela Attach to Process selecionando Debug > Attach to Process...

2. Definir Transport como Default

3. Selecionar Revit.exe

4. Selecionar Attach

Com o Visual Studio anexado ao Revit, abra o código-fonte Wall.ByCurveAndHeight em Wall.cs. Podemos encontrar isso no Gerenciador de soluções em Libraries > RevitNodes > Elements na região Public static constructors do arquivo. Defina um ponto de quebra no construtor do tipo de parede para que quando o nó for executado no Dynamo, o processo seja interrompido e possamos percorrer cada linha de código individualmente. Normalmente, os construtores do tipo sem toque do Dynamo começam com By<parameters>.

1. O arquivo de classe com o construtor para Wall.ByCurveAndHeight

2. Defina um ponto de quebra clicando à esquerda do número da linha ou clicando com o botão direito do mouse na linha de código e selecione Breakpoint > Insert Breakpoint.

Com o ponto de quebra definido, precisamos que o processo seja executado através da função Wall.ByCurveAndHeight. A função pode ser executada novamente no Dynamo reconectando um fio a uma de suas portas, o que forçará o nó a ser executado novamente. O ponto de quebra será atingido no Visual Studio.

1. O ícone do ponto de quebra muda quando é pressionado

2. A janela Pilha de chamadas mostrando o método ativo seguinte

Agora, passe o cursor sobre cada linha no construtor até que a exceção seja atingida. O código realçado em amarelo é a próxima declaração a ser executada.

1. As ferramentas de depuração para navegação no código

2. Pressionar Step Over para executar o código realçado e, em seguida, suspender a execução após a função retornar

3. A próxima instrução a ser executada, indicada pelo realce e pela seta amarelas

Se continuarmos a percorrer a função, veremos a exceção exibida na janela do DynamoRevit. Observando a janela Pilha de chamadas, poderemos ver que a exceção foi originalmente acionada com base em um método chamado Autodesk.Revit.CurveAPIUtils.CreateNurbsCurve. Felizmente, a exceção é tratada aqui, portanto, o Dynamo não teve um erro fatal. O processo de depuração forneceu contexto para o problema, trazendo-nos para outro método no código-fonte.

Como não é uma biblioteca de código aberto, não poderemos fazer alterações. Agora que temos mais informações, poderemos relatar o problema com mais contexto preenchendo um problema do github ou poderemos propor uma solução alternativa para esse problema, fazendo uma solicitação de extração.

1. Quando pressionamos a instrução que causa a exceção em Walls.cs, o processo de depuração nos aproxima o mais possível da causa do problema no código do usuário dentro de ProtoToRevitCurve.cs

2. A declaração que causou a exceção em ProtoToRevitCurve.cs

3. Na Pilha de chamadas, podemos ver que a exceção é proveniente do código que não é do usuário

4. Uma janela pop-up que nos fornece informações sobre a exceção

Esse processo pode ser aplicado a qualquer arquivo de origem com o qual estamos trabalhando. Se estivermos desenvolvendo uma biblioteca de nós sem toque para o Dynamo Studio, poderemos abrir a origem da biblioteca e anexar um processo do Dynamo para depurar a biblioteca de nós. Mesmo que tudo funcione perfeitamente, a depuração é uma ótima maneira de explorar o código e descobrir como as coisas estão funcionando.

Extrair a compilação mais recente

Esse processo é quase idêntico à extração de alterações para o Dynamo, exceto que precisaremos garantir que estamos na ramificação correta. Use o comando git branch no repositório do DynamoRevit para ver quais ramificações estão disponíveis localmente e quais estão desmarcadas.

cd C:\Users\username\Documents\GitHub\DynamoRevit define o diretório atual para o repositório do DynamoRevit. git branch verifica se estamos na ramificação correta, RC2.13.1_Revit2023. git pull origin RC2.13.1_Revit2023 extrai as alterações da ramificação RC2.13.1_Revit2023 da origem remota.

A origem simplesmente aponta para a URL original que clonamos.

Temos de ter certeza de qual é a ramificação em que estamos atualmente e qual é a que estamos extraindo para evitar, por exemplo, a extração de alterações de RC2.13.1_Revit2023 para Revit2018.

Conforme mencionado em Compilar o Dynamo da origem, quando estivermos prontos para enviar uma alteração ao repositório do DynamoRevit, poderemos criar uma solicitação de extração seguindo as diretrizes da equipe do Dynamo definidas na seção Solicitações de extração.

A origem do Dynamo está hospedada no Github para que qualquer pessoa possa clonar e fazer contribuições. Neste capítulo, analisaremos como clonar o repositório usando o git, compilar os arquivos de origem com o Visual Studio, executar e depurar uma compilação local e extrair as novas alterações do Github.

Localizar os repositórios do Dynamo no Github

O Github é um serviço de hospedagem baseado no git, um sistema de controle de versão para rastrear alterações e coordenar o trabalho entre as pessoas. O Git é uma ferramenta que podemos aproveitar para fazer download dos arquivos de origem do Dynamo e mantê-los atualizados com alguns comandos. O uso desse método evitará o trabalho desnecessário e inerentemente confuso de fazer o download e substituir manualmente os arquivos de origem em cada atualização. O sistema de controle de versão git rastreará as diferenças entre um repositório de código local e remoto.

A origem do Dynamo está hospedada no DynamoDS Github neste repositório: https://github.com/DynamoDS/Dynamo

Arquivos de origem do Dynamo.

1. Clonar ou fazer o download de todo o repositório

2. Visualizar outros repositórios do DynamoDS

3. Arquivos de origem do Dynamo

4. Arquivos específicos do Git

Extrair o repositório do Dynamo usando o git

Antes de clonar o repositório, precisamos instalar o git. Siga este guia curto para obter as etapas de instalação e como configurar um nome de usuário e e-mail do github. Neste exemplo, usaremos o git na linha de comando. Esse guia presume que você esteja usando o Windows, mas também é possível usar o git no Mac ou Linux para clonar a origem do Dynamo.

Precisamos de uma URL para o repositório do Dynamo para clonar. Essa URL pode ser encontrada no botão “Clonar ou fazer o download” na página do repositório. Copie a URL para colar no prompt de comando.

1. Selecionar “Clonar ou fazer o download”

2. Copiar a URL

Com o git instalado, podemos clonar o repositório do Dynamo. Comece abrindo o prompt de comando. Em seguida, use o comando de alteração de diretório cd para navegar até a pasta na qual desejamos que os arquivos de origem sejam clonados. Neste caso, criamos uma pasta chamada Github em Documents.

cd C:\Users\username\Documents\GitHub

Substitua “username” por seu nome de usuário

Na próxima etapa, executaremos um comando git para clonar o repositório do Dynamo para o local que especificamos. A URL no comando é obtida clicando no botão “Clonar ou fazer o download” no Github. Execute esse comando no terminal de comando. Observe que isso clonará a ramificação mestre de repositório do Dynamo, que é o código mais atualizado do Dynamo, e conterá a versão mais recente do código do Dynamo. Essa ramificação muda diariamente.

git clone https://github.com/DynamoDS/Dynamo.git

Saberemos que o git está funcionando se a operação de clonagem tiver sido concluída com êxito. No gerenciador de arquivos, navegue até o diretório onde você clonou para ver os arquivos de origem. A estrutura de diretórios deve ser idêntica à ramificação mestre do repositório do Dynamo no Github.

1. Arquivos de origem do Dynamo

2. Arquivos do Git

Compilar o repositório usando o Visual Studio

Com os arquivos de origem agora clonados em nosso computador local, podemos compilar um arquivo executável para o Dynamo. Para fazer isso, precisamos configurar o Visual Studio IDE e assegurar que o .NET Framework e o DirectX estejam instalados.

• Faça o download e instale o Microsoft Visual Studio Community 2015, um IDE gratuito e completo (ambiente de desenvolvimento integrado – as versões posteriores também podem funcionar)

• Faça o download e instale o Microsoft .NET Framework 4.5 ou posterior

• Instale o Microsoft DirectX do repositório local do Dynamo (Dynamo\tools\install\Extra\DirectX\DXSETUP.exe)

O .NET e o DirectX podem já estar instalados.

Quando tudo estiver pronto, podemos iniciar o Visual Studio e abrir a solução Dynamo.All.sln localizada em Dynamo\src.

1. Selecionar File > Open > Project/Solution

2. Navegar até o repositório do Dynamo e abrir a pasta src

3. Selecionar o arquivo da solução Dynamo.All.sln

4. Selecionar Open

Antes de podermos compilar a solução, algumas configurações devem ser especificadas. Primeiro, devemos compilar uma versão de depuração do Dynamo para que o Visual Studio possa coletar mais informações durante a depuração para nos ajudar a desenvolver, e queremos a AnyCPU como destino.

Elas se tornarão pastas dentro da pasta bin

1. Para este exemplo, escolhemos Debug como a Configuração da solução

2. Definir a Plataforma de soluções como Any CPU

Com o projeto aberto, podemos compilar a solução. Esse processo criará um arquivo DynamoSandbox.exe que podemos executar.

A compilação do projeto restaurará as dependências do NuGet.

1. Selecionar Build > Build Solution.

2. Verificar se a compilação foi bem-sucedida na janela Saída. Deve ser semelhante a ==== Build: 69 succeeded, 0 failed, 0 up-to-date, 0 skipped ====

Executar uma compilação local

Se o Dynamo for compilado com êxito, uma pasta bin será criada no repositório do Dynamo com o arquivo DynamoSandbox.exe. No nosso caso, estamos compilando com a opção Depurar, portanto, o arquivo executável estará localizado em bin\AnyCPU\Debug. A execução dessa ação abrirá uma compilação local do Dynamo.

1. O executável do DynamoSandbox que acabamos de criar. Execute isso para iniciar o Dynamo.

Agora estamos quase totalmente preparados para começar a desenvolver o Dynamo.

Para obter instruções sobre como compilar o Dynamo para outras plataformas (por exemplo, Linux ou OS X), visite esta página wiki.

Depurar uma compilação local usando o Visual Studio

A depuração é um processo de identificação, isolamento e correção de um problema ou bug. Após o Dynamo ter sido criado com êxito da origem, poderemos usar diversas ferramentas no Visual Studio para depurar um aplicativo em execução, por exemplo, o complemento DynamoRevit. Podemos analisar seu código-fonte para localizar a causa de um problema ou observar o código em execução no momento. Para obter uma explicação mais detalhada de como depurar e navegar no código no Visual Studio, consulte o Documentos do Visual Studio.

Para o aplicativo independente do Dynamo, DynamoSandbox, abordaremos duas opções para depuração:

• Compilar e iniciar o Dynamo diretamente no Visual Studio

• Anexar o Visual Studio a um processo em execução do Dynamo

Iniciar o Dynamo no Visual Studio recompila a solução para cada sessão de depuração, se necessário; portanto, se fizermos alterações na origem, elas serão incorporadas ao depurar. Com a solução Dynamo.All.sln ainda aberta, selecione Debug, AnyCPU e DynamoSandbox nos menus suspensos e clique em Start. Isso compilará o Dynamo, iniciará um novo processo (DynamoSandbox.exe) e anexará o depurador do Visual Studio a ele.

Compilar e iniciar o aplicativo diretamente no Visual Studio

1. Definir a configuração como Debug

2. Definir a plataforma como Any CPU

3. Definir o projeto de inicialização como DynamoSandbox

4. Clicar em Start para iniciar o processo de depuração

Como alternativa, podemos desejar depurar um processo do Dynamo que já está em execução para solucionar um problema com um gráfico ou pacote específico aberto. Para essa finalidade, abriríamos os arquivos de origem do projeto no Visual Studio e anexaríamos a um processo do Dynamo em execução usando o item de menu de depuração Attach to Process.

Anexar um processo em execução ao Visual Studio

1. Selecionar Debug > Attach to Process...

2. Escolher DynamoSandbox.exe

3. Selecionar Attach

Em ambas as situações, estamos anexando o depurador a um processo que desejamos depurar. Podemos definir pontos de quebra no código antes ou após iniciar o depurador que fará com que o processo pause imediatamente antes de executar essa linha de código. Se uma exceção não capturada for gerada durante a depuração, o Visual Studio pulará para onde ela ocorreu no código-fonte. Esse é um método eficiente para localizar falhas simples e exceções não tratadas e também para entender o fluxo de execução de um aplicativo.

Durante a depuração do DynamoSandbox, definimos um ponto de quebra no construtor do nó Color.ByARGB que faz com que o processo do Dynamo pause quando o nó é instanciado. Se esse nó estava gerando uma exceção ou causando um erro fatal no Dynamo, poderíamos passar por cada linha no construtor para descobrir onde o problema estava ocorrendo.

1. O ponto de quebra

2. A pilha de chamadas mostrando a função que está sendo executada no momento e as chamadas de função anteriores.

Na próxima seção, Compilar o DynamoRevit da origem, analisaremos um exemplo específico de depuração e explicaremos como definir pontos de quebra, passar pelo código e ler a pilha de chamadas.

Extrair a compilação mais recente

Como a origem do Dynamo está hospedada no Github, a maneira mais fácil de manter os arquivos de origem locais atualizados é extraindo as alterações usando os comandos git.

Usando a linha de comando, defina o diretório atual para o repositório do Dynamo:

cd C:\Users\username\Documents\GitHub\Dynamo

Substitua "username" por seu nome de usuário

Use o seguinte comando para extrair as alterações mais recentes:

git pull origin master

1. Aqui podemos ver que o repositório local foi atualizado com as alterações do remoto.

Além de extrair as atualizações, há mais quatro fluxos de trabalho git com os quais se familiarizar.

• Bifurcar o repositório do Dynamo para criar uma cópia separada do original. Todas as alterações feitas aqui não afetarão o repositório original e as atualizações poderão ser buscadas ou enviadas com solicitações de extração. A bifurcação não é um comando git, mas é um fluxo de trabalho que o github adiciona – o modelo de solicitação de extração bifurcado é um dos fluxos de trabalho mais comuns para contribuir para projetos de código-fonte aberto on-line. Vale a pena aprender se você deseja contribuir no Dynamo.

• Ramificação – trabalhar em experimentos ou em novas operações isolados de outros trabalhos em ramificações. Isso facilita o envio de solicitações de extração.

• Fazer confirmações com frequência, após completar uma unidade de trabalho e após uma alteração que possa desejar ser desfeita. Os registros de confirmações mudam para o repositório e serão visíveis ao fazer uma solicitação de extração para o repositório principal do Dynamo.

• Criar solicitações de extração quando as alterações estiverem prontas para serem oficialmente propostas para o repositório principal do Dynamo.

A equipe do Dynamo tem instruções específicas sobre a criação de solicitações de extração. Consulte a seção Solicitações de extração nesta documentação para obter itens mais detalhados a serem tratados.

Consulte esta página da documentação para obter uma lista de referência de comandos git.

Se você estiver procurando exemplos sobre como desenvolver para o Dynamo, consulte os recursos abaixo:

Repositórios de amostras

Essas amostras são modelos do Visual Studio que você pode usar para iniciar seu próprio projeto:

• : modelo para os nós Sem toque básicos.

  • Retornar várias saídas:

  • Usar um objeto de geometria nativo do Dynamo:

  • Exemplo de propriedade (nó de consulta):

• : modelos para os nós NodeModel básicos e personalização da vista.

  • Modelo básico do NodeModel:

    • Definir atributos de nó (nomes de entrada/saída, descrições, tipos):

    • Retornar um nó nulo se não houver entradas:

    • Criar uma chamada de função:

  • Modelo básico de personalização da vista do NodeModel: , , ,

    • Alertar a interface do usuário que um elemento precisa ser atualizado:

    • Personalizar o NodeModel:

    • Definir os atributos do controle deslizante:

    • Determinar a lógica de interação do controle deslizante:

• : modelos para o nó Sem toque, interface do usuário personalizada, testes e extensões de vista.

  • • Criar um nó de interface de usuário básico e personalizado:

    • Criar um menu suspenso:

  • • Testes do sistema:

    • Testes do nó Sem toque:

  • :

    • Exemplo de nós Sem toque, incluindo um que implementa IGraphicItem para afetar a renderização da geometria:

    • Exemplo de nós Sem toque para colorir a geometria usando IRenderPackage:

  • : uma implementação IViewExtension que mostra uma janela sem janela restrita quando seu MenuItem é clicado.

• : modelos para desenvolvimento avançado de pacotes do Dynamo usando o NodeModel.

  • Amostras essenciais:

  • Amostras de geometria:

  • Amostras de interface do usuário:

Estudos de caso

Os desenvolvedores terceiros fizeram contribuições significativas e empolgantes para a plataforma, muitas das quais também são de código aberto. Os projetos a seguir são exemplos excepcionais do que pode ser feito com o Dynamo.

O Ladybug é uma biblioteca Python para carregar, analisar e modificar arquivos de Clima do EnergyPlus (epw).

Honeybee é uma biblioteca Python para criar, executar e visualizar os resultados da análise de luz natural (RADIANCE) e energia (EnergyPlus/OpenStudio).

Bumblebee: um plug-in para interoperabilidade do Excel e do Dynamo (GPL).

Clockwork é uma coleção de nós personalizados para atividades relacionadas ao Revit, bem como outras finalidades, como gerenciamento de lista, operações matemáticas, operações de sequência de caracteres, operações geométricas (principalmente caixas delimitadoras, malhas, planos, pontos, superfícies, UVs e vetores) e painéis.

As extensões são uma poderosa ferramenta de desenvolvimento no ecossistema do Dynamo. Elas permitem que os desenvolvedores direcionem a funcionalidade personalizada com base nas interações e lógica do Dynamo. As extensões podem ser divididas em duas categorias principais, extensões e extensões de vista. Como a nomenclatura indica, a estrutura de extensão da vista permite estender a interface do usuário do Dynamo registrando itens de menu personalizados. As extensões regulares operam de forma muito semelhante, exceto a interface do usuário. Por exemplo, podemos compilar uma extensão que registra informações específicas no console do Dynamo. Esse cenário não requer uma interface do usuário personalizada e, portanto, também pode ser realizado usando uma extensão.

Estudo de caso de extensão

Seguindo o exemplo SampleViewExtension do repositório Github do DynamoSamples, vamos percorrer as etapas necessárias para criar uma janela simples sem janela restrita que exibe os nós ativos no gráfico em tempo real. Uma extensão de vista requer que criemos uma interface do usuário para a janela e vinculemos valores a um modelo de vista.

1. A janela de extensão da vista foi desenvolvida seguindo o exemplo SampleViewExtension no repositório Github.

Embora possamos compilar o exemplo desde o início, também é possível fazer o download e criar o repositório DynamoSamples para servir como referência.

Este percurso virtual fará referência específica ao projeto denominado SampleViewExtension encontrado em DynamoSamples/src/.

Como implementar uma extensão de vista

Uma extensão de vista tem três partes essenciais:

• Uma montagem contendo uma classe que implementa IViewExtension, bem como uma classe que cria um modelo de vista

• Um arquivo .xml que informa ao Dynamo onde ele deve procurar por essa montagem no tempo de execução e o tipo de extensão

• Um arquivo .xaml que vincula os dados à exibição gráfica e determina a aparência da janela

1. Criar a estrutura do projeto

Comece criando um novo projeto Class Library chamado SampleViewExtension.

1. Criar um novo projeto selecionando File > New > Project

2. Selecionar Class Library

3. Nomear o projeto SampleViewExtension

4. Selecionar Ok

Neste projeto, precisaremos de duas classes. Uma classe implementará IViewExtension e a outra que implementará NotificationObject. IViewExtension conterá todas as informações sobre como nossa extensão será implantada, carregada, referenciada e eliminada. NotificationObject fornecerá notificações de alterações no Dynamo e IDisposable quando ocorrer uma alteração, a contagem será atualizada de acordo.

1. Um arquivo de classe denominado SampleViewExtension.cs que implementará IViewExtension

2. Um arquivo de classe denominado SampleWindowViewMode.cs que implementará NotificationObject

Para usar o IViewExtension, precisaremos do pacote WpfUILibrary NuGet. A instalação desse pacote instalará automaticamente os pacotes Core, Services e ZeroTouchLibrary.

1. Selecionar a biblioteca WpfUIL

2. Selecionar Install para instalar todos os pacotes dependentes

2. Implementar a classe IViewExtension

Na classe IViewExtension, vamos determinar o que acontece quando o Dynamo é iniciado, quando a extensão é carregada e quando o Dynamo é fechado. No arquivo de classe SampleViewExtension.cs, adicione o seguinte código:

A classe SampleViewExtension cria um item de menu clicável para abrir a janela e conecta-a ao modelo de vista e à janela.

• public class SampleViewExtension : IViewExtension SampleViewExtension herda da interface do IViewExtension e fornece tudo o que precisamos para criar o item de menu.

• sampleMenuItem = new MenuItem { Header = "Show View Extension Sample Window" }; cria um MenuItem e o adiciona ao menu View.

1. O item de menu

• sampleMenuItem.Click += (sender, args) aciona um evento que abrirá uma nova janela quando o item de menu for clicado

• MainGrid = { DataContext = viewModel } define o contexto de dados para a grade principal na janela, referindo-se a Main Grid no arquivo .xaml que criaremos

• Owner = p.DynamoWindow define o proprietário da janela pop-out como Dynamo. Isso significa que a nova janela depende do Dynamo, portanto, ações como minimizar, maximizar e restaurar o Dynamo farão com que a nova janela siga esse mesmo comportamento

• window.Show(); exibe a janela onde as propriedades adicionais da janela foram definidas

3. Implementar o modelo de vista

Agora que estabelecemos alguns dos parâmetros básicos da janela, adicionaremos a lógica para responder a vários eventos relacionados ao Dynamo e instruiremos a interface do usuário a atualizar com base nesses eventos. Copie o seguinte código para o arquivo de classe SampleWindowViewModel.cs:

Essa implementação da classe de modelo de vista ouve o CurrentWorkspaceModel e aciona um evento quando um nó é adicionado ou removido do espaço de trabalho. Isso gera uma alteração de propriedade que notifica a interface do usuário ou elementos vinculados que os dados foram alterados e precisam ser atualizados. O getter ActiveNodeTypes é chamado, o que chama internamente uma função getNodeTypes() de ajuda adicional. Essa função interage em todos os nós ativos na tela, preenche uma sequência de caracteres contendo os nomes desses nós e retorna essa sequência para nossa associação no arquivo .xaml para ser exibido em nossa janela pop-out.

Com a lógica principal da extensão definida, agora vamos especificar os detalhes de aparência da janela com um arquivo .xaml. Tudo que precisamos é uma janela simples que exiba a sequência de caracteres usando a associação de propriedade ActiveNodeTypes noTextBlock Text.

1. Clicar com o botão direito do mouse no projeto e selecionar Add > New Item...

2. Selecionar o modelo Controle de usuário que vamos alterar para criar uma janela

3. Nomear o novo arquivo SampleWindow.xaml

4. Selecionar Add

No código da janela .xaml, precisaremos vincular SelectedNodesText a um bloco de texto. Adicione o seguinte código a SampleWindow.xaml:

• Text="{Binding ActiveNodeTypes}" vincula o valor da propriedade de ActiveNodeTypes em SampleWindowViewModel.cs ao valor TextBlock Text na janela.

Agora, inicializaremos a janela de amostra no arquivo de backup .xaml C# SampleWindow.xaml.cs. Adicione o seguinte código a SampleWindow.xaml:

A extensão da vista agora está pronta para ser criada e adicionada ao Dynamo. O Dynamo requer um arquivo xml para registrar nossa saída .dll como uma extensão.

1. Clicar com o botão direito do mouse no projeto e selecionar Add > New Item...

2. Selecionar o arquivo XML

3. Nomear o arquivo SampleViewExtension_ViewExtensionDefinition.xml

4. Selecionar Add

• O nome do arquivo segue a norma do Dynamo para fazer referência a uma montagem de extensão como esta: "extensionName"_ViewExtensionDefinition.xml

No arquivo xml, adicione o seguinte código para informar ao Dynamo onde procurar a montagem de extensão:

• Neste exemplo, compilamos a montagem na pasta de projeto padrão do Visual Studio. Substitua o destino <AssemblyPath>...</AssemblyPath> pela localização da montagem.

A última etapa é copiar o arquivo SampleViewExtension_ViewExtensionDefinition.xml para a pasta de extensões de vista do Dynamo localizada no diretório de instalação C:\Program Files\Dynamo\Dynamo Core\1.3\viewExtensions do Dynamo Core. É importante observar que há pastas separadas para extensions e viewExtensions. Colocar o arquivo xml na pasta incorreta pode causar falha ao carregar corretamente no tempo de execução.

1. O arquivo .xml que copiamos para a pasta de extensões de vista do Dynamo

Esta é uma introdução básica às extensões da vista. Para um estudo de caso mais sofisticado, consulte o pacote DynaShape, um projeto de código aberto no Github. O pacote usa uma extensão de vista que permite a edição ao vivo na vista do modelo do Dynamo.