revit-template-migration

# Revit Template Migration The dotnet template engine has no in-place upgrader. Generate an equivalent project from the target template version, then use the diff between that generated project and the current project as the migration plan. The generated output is the source of truth for the selected template version and options. ## When to use - Upgrading a scaffolded add-in, module, benchmark, test project, or solution to a newer template or SDK version. - Adding a template option such as a bundle, installer, tests, or CI to an existing scaffold. ## When not to use - Starting a new project from scratch — that is `scaffolding-revit-projects`. - Adding or removing a supported Revit year within an existing project — that is `revit-multi-version-configuration`. ## Workflow ### Step 1: Generate a target reference Install a new templates version. Create the same template type in an empty temporary directory, with the name and options the current project carries. ```shell dotnet new install Nice3point.Revit.Templates dotnet new <template-short-name> --help dotnet new <template-short-name> --name <ProjectName> --output <reference-directory> <options> ``` Match the project/solution name. A different name shifts namespaces and generated paths across the diff. ### Step 2: Review the generated diff Compare the reference directory with the current project or solution. ```shell git diff --no-index -- <current-directory> <reference-directory> ``` Treat every difference as a review item. Take template-generated infrastructure and configuration changes that the current project needs. Keep project identity, business logic, and deliberate product-specific customization unless the target template requires a compatible rewrite. ### Step 3: Apply the reviewed changes Update each project only from the matching generated template type. Keep `.addin`, GUIDs, deployment logic and dynamic-loading configuration in the original project. ### Step 4: Verify Build every declared `Debug.RNN` and `Release.RNN` configuration. Run every generated pipeline path selected by the project: tests, installer, bundle, or release preparation. ## Validation - [ ] The reference uses the exact target template version, short name, name, and options. - [ ] The generated reference was compared with the current project or solution before changes were applied. - [ ] Only reviewed template changes were transferred. - [ ] Project identity and business logic were preserved. - [ ] Every declared configuration and selected output path succeeds. ## Common Pitfalls | Pitfall | Correct approach | |-----------------------------------------------------------------|------------------------------------------------------------------------| | Generating the latest template when the target version is older | Install and generate the exact target version before comparing. | | Comparing different template options | Match every current option for a meaningful diff. | | Copying a generated tree over the existing project | Transfer reviewed changes selectively and preserve project-owned code. | | Applying an application configuration to a module | Compare each project with its own template type. |