# Definir a organização de pacotes personalizados no Dynamo 2.0 e superior
A obtenção de um layout desejado para o pacote depende dos tipos de nós que você incluirá no pacote. Os nós derivados do modelo de nó, os nós ZeroTouch e os nós personalizados têm um processo ligeiramente diferente para definir a categorização. É possível misturar e combinar esses tipos de nó dentro do mesmo pacote, mas isso exigirá uma combinação das estratégias descritas abaixo.
## NodeModel
Por padrão, as bibliotecas NodeModel são organizadas com base na estrutura de classes.
```c#
namespace SampleLibraryUI.Examples
```
```c#
// Class Attribute
[NodeName("MyNodeModel")]
public class MyNewNodeModel : NodeModel
// or
// Constructor
public ButtonCustomNodeModel()
{
this.Name = "MyNodeModel";
}
```
O nó ficará localizado em Complementos em:
```
SampleLibraryUI/Examples/MyNodeModel
```
Também é possível substituir a categoria usando o atributo NodeCategory na classe ou no construtor, como mostrado abaixo.
```c#
// Class Attribute
[NodeCategory("NewSampleLibraryUI.Examples")]
// or
// Constructor
public ButtonCustomNodeModel()
{
this.Category = "NewSampleLibraryUI.Examples";
}
```
O nó agora ficará localizado em Complementos em:
```
NewSampleLibraryUI/Examples/MyNodeModel
```
## ZeroTouch
As bibliotecas ZeroTouch também são organizadas com base na estrutura de classes por padrão.
```c#
namespace MyZTLibrary
```
```c#
public class Utilities
{
public double doubleValue(double num)
{
return num * 2;
}
}
```
O nó ficará localizado em Complementos em:
```
MyZTLibrary/Utilities/doubleValue
```
Também é possível substituir a localização da estrutura da classe usando um arquivo XML de personalização do Dynamo.
* O arquivo XML deve ser nomeado adequadamente e ser incluído na pasta `extra` do pacote
* `PackageName_DynamoCustomization.xml`
```xml
MeshToolkit
MeshToolkit
Display
```
## CustomNodes
Os nós personalizados são organizados com base no `Category Name` especificado durante a criação dos nós (usando a caixa de diálogo Novo nó personalizado).
**AVISO**\
O uso da notação de ponto em nomes de nós ou categorias resultará em subcategorias aninhadas adicionais. O `.` funcionará como um delimitador para determinar a hierarquia adicional. Esse é um novo comportamento na biblioteca para o Dynamo 2.0.
O nome da categoria pode ser atualizado posteriormente no arquivo .dyf (XML ou JSON)
```json
{
"Uuid": "85066088-1616-40b1-96e1-c33e685c6948",
"IsCustomNode": true,
"Category": "MyCustomNodes.Utilities.Actions",
"Description": "This is an example custom nodes.",
"Name": "doubleValue",
"ElementResolver": {
"ResolutionMap": {}
},...
```
```xml
```
## Estratégias de migração de nós do pacote
Quando o autor de um pacote decide renomear um nó existente anterior em uma nova versão, ele deve fornecer um meio para migrar gráficos que contêm nós com os nomes antigos. Isso pode ser feito das seguintes maneiras:
Os nós **ZeroTouch** usam um arquivo `Namespace.Migrations.XML` localizado na pasta `bin` dos pacotes, como:
`MyZeroTouchLib.MyNodes.SayHello` para `MyZeroTouchLib.MyNodes.SayHelloRENAMED`
```xml
MyZeroTouchLib.MyNodes.SayHello
MyZeroTouchLib.MyNodes.SayHelloRENAMED
```
Os **nós derivados do NodeModel** usam o atributo `AlsoKnownAs` na classe, como:
`SampleLibraryUI.Examples.DropDownExample` para `SampleLibraryUI.Examples.DropDownExampleRENAMED`
```c#
namespace SampleLibraryUI.Examples
{
[NodeName("Drop Down Example")]
[NodeDescription("An example drop down node.")]
[IsDesignScriptCompatible]
[AlsoKnownAs("SampleLibraryUI.Examples.DropDownExample")]
public class DropDownExampleRENAMED : DSDropDownBase
{
...
}
{
```