菜单
SmartCon Revit plugin build guide. Multi-version build configurations (R19/R21/R24/R25), correct restore/build commands, CI/CD workflow, branch protection. Triggers on: build, deploy, release, compile, dotnet build, configuration. Keywords: SmartCon, Revit, build, deploy, release, R19, R21, R24, R25, net48, net8, restore, CI/CD.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Revit plugin development best practices and patterns. Covers threading/Async deadlocks, Transaction patterns, ExternalEvent architecture, MVVM rules, DI setup, and common pitfalls. Essential for C# Revit add-in developers working with WPF and .NET. Keywords: Revit API, ExternalEvent, Transaction, IExternalCommand, IExternalApplication, threading, deadlock, Task.Run, FireAndForget, MVVM, WPF, DI.
Net48/net8 WPF compatibility rules for Revit plugins. Use when writing WPF code, creating dialogs, showing windows, using Dispatcher, accessing Application.Current, debugging net48-only crashes in Revit add-ins, when the WPF DockablePane freezes after a FireAndForget import (LMB dead, RMB unfreezes), OR when a ContextMenu MenuItem is greyed out in net48 but works in net8 — see §'dotnet/wpf#4078 — MenuItem CommandParameter ignored in net48' for the documented bug and the MenuItemCommandParameterRequery workaround.
Conventions for SmartCon domain documentation in docs/domain/. Use when adding a new domain class or interface to SmartCon.Core, when updating existing model/interface docs, when running or interpreting the validate-docs.ps1 validator, when reorganizing docs/domain/ structure, or when the user references the domain documentation validator. Covers the docs/domain/{models,interfaces}/ layout, the per-module .md file split, the frontmatter convention, the validator's classification logic, and known orphan sources (nested types, cross-assembly types, sub-headings).
SmartCon structured logging conventions. Use when reading or writing smartcon.log / formula-diagnostic.log, when adding log calls, when analyzing cross-method correlation via OpId, when debugging scope chain issues, when migrating code from [Cat] prefix to BeginScope, or when the user references Phase 1/2 logging migration. Covers log file locations, scope nesting, OpId correlation, IsEnabled checks, known false-positives in grep audits, AND the critical gotcha that custom Debug.* configurations do not auto-define the DEBUG symbol (so Debug-level lines are silently dropped unless Directory.Build.props adds them).
Unit + integration testing patterns for SmartCon Revit plugin. xUnit + Moq, .NET 8 / net48 multi-version. Covers Revit API mocking limitations, test seams, fake implementations, Moq gotchas with async/generic, integration test frameworks, Jeremy Tammik recommendations. Use when writing, updating, or running tests for SmartCon.
基于 SOC 职业分类
| name | smartcon-build-guide |
| description | SmartCon Revit plugin build guide. Multi-version build configurations (R19/R21/R24/R25), correct restore/build commands, CI/CD workflow, branch protection. Triggers on: build, deploy, release, compile, dotnet build, configuration. Keywords: SmartCon, Revit, build, deploy, release, R19, R21, R24, R25, net48, net8, restore, CI/CD. |
| license | MIT |
| metadata | {"author":"AGK Engineering","version":"1.0.0"} |
Multi-version Revit plugin build configurations and CI/CD workflow.
| Config | Revit | TFM | Command |
|---|---|---|---|
Debug.R25 | 2025-2026 | net8.0-windows | dotnet build src/SmartCon.App/SmartCon.App.csproj -c Debug.R25 |
Debug.R24 | 2024 | net48 | dotnet build src/SmartCon.App/SmartCon.App.csproj -c Debug.R24 |
Debug.R21 | 2021-2023 | net48 | dotnet build src/SmartCon.App/SmartCon.App.csproj -c Debug.R21 |
Debug.R19 | 2019-2020 | net48 | dotnet build src/SmartCon.App/SmartCon.App.csproj -c Debug.R19 |
Tests: dotnet test src/SmartCon.Tests/SmartCon.Tests.csproj -c Debug.R25
Build individual configurations for quick testing during development. Does NOT deploy to Revit.
dotnet build src/SmartCon.App/SmartCon.App.csproj -c Debug.R25
dotnet build src/SmartCon.App/SmartCon.App.csproj -c Debug.R24
dotnet build src/SmartCon.App/SmartCon.App.csproj -c Debug.R21
dotnet build src/SmartCon.App/SmartCon.App.csproj -c Debug.R19
ONLY use after user has manually tested changes in Revit. This builds ALL configurations AND copies files to Revit addins folders.
build-and-deploy.bat
WARNING: Do NOT run build-and-deploy.bat during development. Use individual dotnet build commands instead.
When making changes that affect compilation (new APIs, #if directives, project files):
# Build ALL 4 configurations (for verification, NOT deploy)
dotnet build src/SmartCon.App/SmartCon.App.csproj -c Debug.R25
dotnet build src/SmartCon.App/SmartCon.App.csproj -c Debug.R24
dotnet build src/SmartCon.App/SmartCon.App.csproj -c Debug.R21
dotnet build src/SmartCon.App/SmartCon.App.csproj -c Debug.R19
# OR for final deploy (only after user testing!)
build-and-deploy.bat
# WRONG — fallback to RevitAPI 2021.*, false errors CS0618
dotnet restore src/SmartCon.App/SmartCon.App.csproj
# CORRECT — configuration tells restore which RevitAPI version
dotnet restore src/SmartCon.App/SmartCon.App.csproj -p:Configuration=Debug.R25
--no-restoreNice3point.Revit.Api.RevitAPI is pulled with VersionOverride that depends
on $(RevitVersion). Each configuration must produce a fresh
obj/project.assets.json that targets the right Revit API year (2021.,
2022., 2025.*). Once an assets.json is written, it is reused on the
next build regardless of the new -c flag unless you re-restore.
This is why build-and-deploy.bat runs dotnet build WITHOUT
--no-restore for every configuration (lines 29, 35, 41, 47): the
restore step is part of the build, and produces a clean assets file.
# WRONG — assets.json from previous config is reused, R21 build
# sees the R25 RevitAPI and explodes with CS0246 ForgeTypeId (added
# in Revit 2022, not in 2021.*).
dotnet build src/SmartCon.App/SmartCon.App.csproj -c Debug.R25
dotnet build src/SmartCon.App/SmartCon.App.csproj -c Debug.R21 --no-restore
# ^^^^^^^^^^^^^^^^^^^^^^ NEVER do this
# WRONG — separate restore of a different config writes assets.json
# for that config, then subsequent --no-restore build of yet another
# config reuses the wrong assets.
dotnet restore src/SmartCon.App/SmartCon.App.csproj -p:Configuration=Debug.R24
dotnet build src/SmartCon.App/SmartCon.App.csproj -c Debug.R21 --no-restore
# CORRECT — restore is part of every build, just like build-and-deploy.bat
dotnet build src/SmartCon.App/SmartCon.App.csproj -c Debug.R25
dotnet build src/SmartCon.App/SmartCon.App.csproj -c Debug.R24
dotnet build src/SmartCon.App/SmartCon.App.csproj -c Debug.R21
dotnet build src/SmartCon.App/SmartCon.App.csproj -c Debug.R19
Heuristic for the agent: if you are about to run
dotnet build … --no-restore, you are doing it wrong. The only time
--no-restore is acceptable is the SECOND build of the same
configuration in a row (e.g. after fixing a typo in a source file).
Switching -c always requires a fresh restore.
# WRONG — pulls extra TFM
dotnet build src/SmartCon.sln -c Debug.R25
# CORRECT
dotnet build src/SmartCon.App/SmartCon.App.csproj -c Debug.R25
main requires PR → squash-merge. NEVER push to main directly.Microsoft.Extensions.DependencyInjection 8.x, System.Text.Json 8.xtools\release.bat (local only, CI validates tags)