Desenvolvimento de add-ins para Revit e Civil 3D: o guia completo em português (2026)

As palavras que aparecem no guia todo, explicadas sem jargão.

Add-in (ou plugin) — um arquivo pequeno que adiciona botões e funções novas a um programa que você já usa. Como uma extensão do Chrome, mas para Revit ou Civil 3D.

API — a lista oficial de coisas que a Autodesk permite fazer com o programa pelo seu código. Pense no cardápio de um restaurante: só dá para pedir o que está no cardápio.

SDK — o kit de ferramentas para desenvolvedores. Um pacote oficial que você baixa e que traz os arquivos necessários para seu código conversar com o Revit ou Civil 3D.

DLL — o arquivo final que seu add-in produz. É como um .exe, mas que outro programa carrega dentro.

Compilar — converter seu código (texto) no arquivo final instalável. Como passar um documento do Word para PDF.

Visual Studio — o editor gratuito da Microsoft onde você escreve o código. Parece pesado ao abrir, mas você vai usar 5% das funções.

Framework .NET — a versão do sistema sobre a qual roda seu add-in. Revit e Civil 3D exigem uma específica; você só precisa fazer combinar uma vez.

Bundle — uma pasta com estrutura especial que a Autodesk reconhece ao iniciar. É a forma profissional de entregar um add-in: se copia e pronto.

Transaction — no Revit, o bloco que agrupa as mudanças que você faz no modelo. Toda mudança vai dentro de uma, e é isso que permite desfazê-las.

O que você pode fazer:

• Percorrer todos os elementos do modelo e ler suas propriedades.
• Criar, modificar e apagar elementos programaticamente.
• Exportar dados para Excel, CSV, JSON ou banco de dados.
• Gerar vistas, pranchas e folhas em série.
• Adicionar suas próprias janelas com formulários e opções.
• Escutar eventos (quando o usuário salva, cria ou apaga algo).
• Integrar com sistemas externos: ERP, bancos de dados, serviços web.
• Validar o modelo contra os padrões do seu escritório.

O que NÃO pode fazer:

• Mudar o comportamento interno dos comandos oficiais da Autodesk.
• Acessar partes do programa que a API não expõe.
• Executar o add-in fora do processo do Revit ou Civil 3D.
• Rodar em Mac ou Linux — a API é só Windows.

Revit vs Civil 3D: o que muda

As duas APIs têm dificuldade comparável, mas personalidades distintas.

Revit trabalha com elementos bastante uniformes (paredes, janelas, famílias) e sua API é muito documentada, com comunidade grande. Você encontra resposta para quase qualquer dúvida, embora quase sempre em inglês.

Civil 3D trabalha com objetos mais complexos (corredores, superfícies, alinhamentos, perfis) que têm muito mais partes móveis. A API é igualmente potente mas muito menos documentada, e a comunidade lusófona é quase inexistente. Aí está a dificuldade real — e também a oportunidade.

Além disso, o Civil 3D se apoia na API do AutoCAD: você acaba usando as duas ao mesmo tempo, porque um desenho de Civil 3D também contém entidades puras do AutoCAD.

Tudo o que você precisa antes de escrever a primeira linha.

1. Windows com Revit ou Civil 3D instalado. A versão que você usa no trabalho. Precisa do programa para testar, não só para desenvolver.

2. Visual Studio Community 2022 — gratuito, em visualstudio.microsoft.com. Ao instalar, marque a carga de trabalho "Desenvolvimento desktop com .NET". É a única que você precisa.

3. O SDK do seu produto. Baixe do portal de desenvolvedores da Autodesk buscando o SDK da sua versão. Traz as bibliotecas que seu projeto precisa referenciar e, muito útil, exemplos oficiais que você pode abrir e estudar.

4. Git — git-scm.com ou GitHub Desktop se prefere interface visual. Não é opcional. É sua rede de segurança desde o primeiro dia.

5. Opcional mas muito recomendável:

• RevitLookup (código aberto) — mostra ao vivo todas as propriedades do elemento que você seleciona. É a forma mais rápida de descobrir o que dá para ler.
• Uma IA como copiloto — Claude ou ChatGPT. Encurta drasticamente a curva. O método está em Vibe Coding para engenheiros.

Verifique que está tudo certo

dotnet --version    # deve mostrar 6.0 ou superior
git --version       # qualquer versao moderna

Esta é a parte que separa um add-in que cresce bem de um que fica insustentável em três meses.

A arquitetura: Command → Service → Repository. Três camadas, cada uma com uma só responsabilidade.

O que cada camada faz

Command — é o que o programa executa quando o usuário aperta o botão. Só orquestra: recebe o evento, chama o Service, mostra o resultado. Não toca a API diretamente.

Service — contém a sua lógica: "vigas com menos de 3 m não contam", "o CSV leva esta cabeçalha", "o nome se forma assim". Não sabe nada de Revit nem de Civil 3D — trabalha com objetos de dados simples.

Repository — é o único que conhece a API da Autodesk. Traduz entre os objetos do programa e seus objetos de dados.

Tradução para pastas

MeuPlugin/
  Commands/       -> pontos de entrada
  Services/       -> suas regras de negocio
  Repositories/   -> tudo que toca a API
  Models/         -> objetos de dados puros
  UI/             -> janelas e formularios
  Resources/      -> icones e imagens

As 5 vantagens concretas

1. Atualizável. Quando a Autodesk mudar a API — e sempre muda — você só toca Repositories/. Sua lógica e interface ficam intactas.
2. Testável. Você pode testar o Service sem abrir o programa, simulando dados.
3. Reutilizável. O mesmo Service pode servir ao Revit e ao Civil 3D com Repositories diferentes.
4. Escalável. Adicionar um comando novo é criar um Command e reutilizar os Services existentes.
5. Depurável. Quando algo falha, você sabe em que camada procurar.

O antipadrão que você verá em tutoriais antigos

Um único arquivo gigante com tudo dentro: chamadas à API, cálculos, formatação e janelas misturados. É rapidíssimo no primeiro dia e um pesadelo em três meses. Não faça, mesmo que o add-in pareça pequeno — todos começam pequenos.

Um add-in mínimo tem três peças.

1. O arquivo de projeto (.csproj)

Define que framework você usa e que bibliotecas da Autodesk referencia. É onde se configura se o projeto compila para Revit 2024 ou 2025.

Detalhe importante: as referências às bibliotecas da Autodesk devem ser marcadas para não serem copiadas para a pasta de saída. Já estão no programa; duplicá-las causa conflitos.

2. A classe do comando

É a porta de entrada. No Revit, uma classe que implementa IExternalCommand; no Civil 3D, um método marcado com o atributo CommandMethod. É aqui que o programa entra quando o usuário executa sua ferramenta.

Qualquer mudança no modelo tem que ir dentro de uma transação: se abre, se fazem as mudanças, se confirma. Se algo falhar no meio, tudo é descartado e o modelo fica como estava. É o que permite ao usuário desfazer.

3. O arquivo de registro

Diz ao programa que seu add-in existe.

• No Revit é um arquivo .addin (formato XML) que se coloca numa pasta específica e aponta para seu DLL.
• No Civil 3D você pode carregá-lo manualmente com o comando NETLOAD durante o desenvolvimento, ou registrá-lo com um bundle para que carregue sozinho.

Nomes de comando: uma convenção que você vai agradecer

Prefixe todos seus comandos com as iniciais do seu escritório. Se sua empresa é Zeist, use ZEIST_EXPORTAR_ALINHAMENTOS em vez de EXPORTAR. Evita colisões com outros add-ins e faz o usuário encontrar suas ferramentas digitando o prefixo.

O loop que você vai repetir centenas de vezes.

1. Escrever — o código no Visual Studio.

2. Compilar — Ctrl+Shift+B ou dotnet build. Gera o DLL. Se houver erros, aparecem aqui.

3. Carregar no programa:

• Civil 3D: comando NETLOAD e você seleciona o DLL.
• Revit: você coloca o arquivo .addin na pasta de add-ins e reinicia.

4. Testar — executa seu comando sobre um modelo de teste.

5. Verificar — confere o resultado com seus próprios olhos, não só que não deu erro.

O detalhe que frustra todo mundo no começo

Uma vez que o Revit ou Civil 3D carrega seu DLL, ele o bloqueia. Você não pode recompilar por cima sem fechar o programa. Isso transforma cada iteração em: fechar, compilar, abrir, carregar, testar. Insuportável.

Existem duas soluções habituais:

• Add-in Manager (vem no SDK do Revit) — permite recarregar sem fechar o programa.
• Depuração com "attach to process" — você conecta o Visual Studio ao processo em execução e pode colocar pontos de parada para ver o que acontece linha a linha.

Configurar qualquer uma das duas no começo te economiza horas.

Protocolo de testes mínimo

Antes de dar por bom um comando, teste com:

1. Modelo vazio — não deveria estourar, deveria avisar.
2. Um só elemento — o caso mínimo.
3. Modelo grande de verdade — a performance só aparece aqui.
4. Dados estranhos — nomes com acentos, valores nulos, elementos sem o parâmetro que você espera.

Um comando que se digita pelo teclado funciona, mas ninguém lembra como se chama. Um botão visível na barra superior sim é usado.

Adicionar sua própria aba

A barra superior do Revit e Civil 3D — aquela faixa onde estão "Home", "Insert", "Annotate" — pode ser estendida. Você pode criar uma aba com o nome do seu escritório e colocar ali suas ferramentas agrupadas em painéis.

O registro é feito ao iniciar o programa, através de uma classe que executa durante o carregamento do add-in.

Ícones

Você precisa de dois tamanhos: 16×16 para botões pequenos e 32×32 para os grandes, em formato PNG com fundo transparente. Pode obtê-los em bibliotecas gratuitas como Icons8 ou desenhá-los no Figma.

Os ícones precisam ser copiados junto ao DLL ao compilar — se configura no arquivo de projeto.

Quando faz falta uma janela própria

Um botão que executa algo diretamente cobre a maioria dos casos. Você precisa de uma janela com formulários quando:

• O usuário tem que escolher opções antes de executar.
• É preciso mostrar uma prévia do que vai acontecer.
• O processo é longo e convém uma barra de progresso.
• Você quer salvar as preferências de cada usuário.

Leve em conta que uma interface própria pode dobrar o esforço do add-in. Comece sem ela e adicione só quando o uso real pedir.

Seu add-in funciona na sua máquina. Agora é levá-lo às demais. Quatro níveis, conforme quanta gente usa.

Nível 1 — Manual (1 a 3 usuários)

Você copia o DLL para uma pasta e cada usuário carrega. Para Revit, além disso o arquivo .addin na pasta correspondente.

Funciona, mas cada atualização obriga a repetir o processo pessoa por pessoa.

Nível 2 — Bundle (3 a 20 usuários) — o ponto doce

O formato oficial da Autodesk. É uma pasta com uma estrutura específica que o programa detecta e carrega automaticamente ao iniciar.

MeuPlugin.bundle/
  PackageContents.xml
  Contents/
    Windows/
      MeuPlugin.dll
    Resources/
      icons/

O arquivo PackageContents.xml declara que versões suporta, quem publica e o que carregar. O usuário só precisa copiar a pasta para o diretório de add-ins da Autodesk e reiniciar.

Para a maioria dos escritórios, o caminho termina aqui. É suficiente e não exige infraestrutura.

Nível 3 — Instalador (20 a 100 usuários)

Um .exe ou .msi que faz a instalação sozinho. Ferramentas habituais: Inno Setup (gratuito e simples) ou WiX Toolset (mais potente, mais complexo).

Vantagens: instalação em um clique, desinstalador, e você pode pedir permissões de administrador para instalar para todos os usuários da máquina.

Nível 4 — Atualizações automáticas ou App Store

Para mais de 100 usuários ou distribuição externa. Você precisa de um servidor que sirva as versões e que seu add-in consulte ao iniciar. Se vai vender a terceiros, a Autodesk App Store é o canal oficial, mas exige cadastro como publisher, revisão do código e assinatura digital.

A Autodesk publica versão nova todo ano. Isto é o que realmente acontece.

O que quebra e o que não

Na maioria das vezes não quebra nada: você recompila contra as bibliotecas novas e funciona. Mas às vezes muda uma assinatura de método, algo é marcado como obsoleto ou muda o framework .NET exigido.

A mudança de framework é a mais disruptiva: obriga a recompilar e às vezes a ajustar dependências.

Como suportar várias versões ao mesmo tempo

Três estratégias, da simples à sofisticada:

1. Um branch por versão. Simples mas dobra a manutenção.
2. Um projeto com várias configurações de compilação. Você compila para 2024, 2025 e 2026 do mesmo código, com condicionais onde diferirem.
3. Separar em duas camadas. Toda a lógica numa biblioteca comum, e uma camada fina específica por versão. É exatamente o que a arquitetura do módulo 3 te dá.

Orce a manutenção

Regra prática: entre 15% e 25% do custo inicial por ano. Cobre adaptação a versões novas, correção de erros que aparecem com o uso real, e pequenas melhorias que a equipe vai pedir assim que gostar da ferramenta.

Se alguém te vende um add-in sem mencionar isso, não manteve muitos.

Não há resposta universal. Depende de quatro fatores.

Desenvolva internamente se...

• Você tem alguém com interesse real e tempo protegido para isso (não "quando puder").
• As ferramentas são pequenas e muito específicas do seu critério.
• Você quer construir capacidade interna a médio prazo.
• Você pode assumir que a primeira versão demore mais que o previsto.

Com IA como copiloto essa via é muito mais viável que há cinco anos. O caminho completo está em criar um plugin de Civil 3D com Claude Code.

Encomende fora se...

• A ferramenta é crítica e você não pode depender de uma só pessoa.
• Precisa que esteja pronto em semanas, não meses.
• Requer integrações com sistemas externos ou interface complexa.
• Ninguém da equipe tem tempo real protegido para isso.

Condição inegociável: que o contrato inclua o código-fonte e a documentação. Se o fornecedor fica com o código, você fica preso a ele para cada mudança e cada versão nova da Autodesk.

A via intermediária que costuma funcionar melhor

Encomendar a primeira ferramenta com formação incluída: alguém da sua equipe participa do desenvolvimento e fica com o conhecimento. A segunda vocês já fazem sozinhos.

Os fatores de orçamento estão em quanto custa um add-in.