Inventor Rule-Based Batch Rename for iLogic – safely and efficiently batch-renames 3D parts, assemblies, 2D drawings, and iPart/iAssembly files with Members in an Inventor project. The tool automatically collects related files in assembly browser order, generates new names from a naming template, part numbers, serial numbers, and find/replace rules, and shows a clear input/output preview before execution.
iPart/iAssembly factories and Members are highlighted with different colors, and naming conflicts are either auto-numbered or flagged in red. During execution, the rule copies files, regenerates Members, updates assembly and drawing references, and verifies output completeness. Afterward, it proactively asks whether to clean up old files, obsolete Members, and old Member folders, then automatically opens the primary assembly under its new name.
The workflow prioritizes reference integrity and source-data safety, making it suitable for project renumbering, naming standardization, and full design-copy renaming scenarios.
File
—-
Inventor_Rule_Based_Batch_Rename_iLogic_EN.vb
Installation
————
1. Place the .vb file in Inventor’s External Rule Directory.
2. In Inventor, go to Tools -> Options -> iLogic Configuration and confirm that this folder has been added to the External Rule Directory list.
3. Open a saved IPT, IAM, IDW, or DWG file.
4. Run this rule from External Rules in the iLogic browser.
Input window
————
The rule scans:
– the current 3D part or assembly;
– IPT and IAM files referenced by the current design;
– IDW/DWG files in the same folder with the same base name as a model;
– iPart/iAssembly Members used in assemblies;
– the factory files corresponding to those Members;
– all Members already generated in the factory MemberCacheDir, even if they are not used by the current assembly.
The naming template supports:
– {OriginalName}: the source file base name;
– {PartNumber}: the Inventor Part Number; if empty, the source name is used;
– {Sequence}: a serial number generated from the specified starting value;
– {Type}: 3D or 2D.
Example input:
– Name Template: PRJ-{PartNumber}-{Sequence}
– Find and Replace can both be left blank.
– Start Number: 1
– Digits: 3
– The preview result may look like PRJ-A100-001.ipt.
Use Find to enter text that should be removed from or replaced in the template result, and use Replace to enter the new text. If Replace is left blank, the matched Find text is deleted. Find and Replace are on the second row of the window. After entering them, click the separate Confirm Find/Replace button (“Confirm Find/Replace”) on the right to apply the rule and refresh the list. Hovering over each input box also shows usage tips.
Click the blue Preview Input/Output button (“Preview Input/Output”) in the lower-right corner, next to Execute (“Execute”) and Cancel (“Cancel”). The table then shows each input file and output file name. You can edit the output column manually, or clear the Process checkbox (“Process”) for a row.
Preview Input/Output only refreshes the table. It does not copy, rename, or delete any files. After confirming that the preview is correct, click the Execute button (“Execute”) in the lower-right corner.
The preview list is arranged recursively in occurrence order from the primary assembly browser. Each model’s matching 2D drawing follows immediately after that model. Factories or other files that do not belong to assembly occurrences are placed at the end of the list. Yellow rows indicate iPart/iAssembly Members, blue rows indicate iPart/iAssembly factories, and normal files are white. Name conflicts are still shown in red, which takes priority over the type color.
If different source files produce the same output name from the template, the preview automatically appends -001, -002, and so on to later files so outputs in the same folder with the same extension remain unique. For example, if two parts both have the Part Number A100, the outputs automatically become A100.ipt and A100-001.ipt. If a duplicate name is created again after manual editing of the output column, the affected row immediately turns red and execution is blocked.
If a generated target name already exists locally, the preview automatically appends -001, -002, and so on until it finds an available output path, then shows a warning dialog that lists up to 10 skipped existing paths. If more paths were skipped, the dialog also reports how many additional files were omitted from the list. If you manually edit the output column to an existing local target file, that row turns PeachPuff with the status “Target file already exists locally”, and Execute is blocked to prevent overwriting.
3D assemblies and 3D parts also may not share the same base name. If an assembly and the first part both resolve to A100, the assembly keeps A100.iam first, and the part is automatically renamed to A100-001.ipt. The drawing with the same name as that part is correspondingly renamed to A100-001.idw.
If a child component is going to be renamed, its parent assembly and parent drawing must also remain checked and use the new file names. The rule verifies this before execution to prevent mixing old and new files or creating broken links after old files are deleted.
2D rules
——–
2D drawings in the same folder with the same base name automatically follow the 3D model. For example:
Input: A100.ipt, A100.idw
Template: PRJ-{PartNumber}
Output: PRJ-A100.ipt, PRJ-A100.idw
iPart/iAssembly Member rules
—————————-
If a Member file name starts with the factory file name, the Member automatically inherits the factory’s new prefix. For example:
Input: A.ipt (factory), A-4.ipt (Member)
Factory output: 002.ipt
Member output: 002-4.ipt
The rule uses Inventor file copies to preserve InternalName, then redirects references in the new assemblies and drawings through ReplaceReference. This avoids the reference loss that can happen with ordinary file-explorer renaming.
When a factory is renamed, the rule updates the factory table and regenerates all existing Members. After all new Members and references are fully validated, the rule proactively asks whether to delete obsolete old Member child files and the original obsolete Member folder.
To avoid accidental deletion, the entire old Member folder is deleted recursively only when the old factory’s MemberCacheDir is a dedicated directory that is in the same folder as the old factory and whose folder name equals the old factory base name, and only after all new outputs have already been moved out. Shared directories, workspace root directories, or reparse-point directories are never deleted recursively.
Inventor may change the Member cache subfolder after a factory rename. During execution, the rule reads the new factory’s MemberCacheDir and updates assembly references using the full path actually generated by Inventor, instead of assuming that the new Member and old Member are in the same directory.
Output window
————-
After completion, the tool shows an itemized log for copying, reference updates, old-file deletion, and other actions. You can click Copy Log (“Copy Log”). When all operations succeed, the rule automatically reopens and activates the primary assembly under its new name. When started from a drawing, it preferentially opens the assembly directly referenced by that drawing; if there is no primary assembly, it opens an assembly from the scan results.
Safety notes
————
– The new design is created and validated first, and the old-file cleanup confirmation appears only after that succeeds.
– The cleanup confirmation defaults to No (“No”). Choosing No keeps the entire old design. Choosing Yes (“Yes”) deletes the old files, obsolete Members, and the original Member folder only when it meets the safety conditions.
– If an error such as file locking occurs during deletion, validated new files are kept and deletions are not rolled back.
– Back up the project before execution. Files managed by Vault should be renamed inside Vault, not with this rule.
– Read-only files are excluded by default.
– Rows in the factory table that have never generated files are not generated solely for renaming.
Assembly hierarchy protection
—————————–
– The rule copies the complete IAM file and only updates file references; it does not intentionally move, delete, or flatten occurrences.
– Before execution, it records each source assembly’s top-level occurrence order, count, suppression state, direct referenced paths, and assembly constraint count.
– After reference updates, it opens each renamed assembly and compares the new snapshot against the source snapshot after applying the rename-path mapping.
– It also checks that no new file still points to any old path renamed in the current run.
– Old-file cleanup is offered only after both hierarchy validation and reference-closure validation succeed.
Troubleshooting
—————
– If an assembly contains a lightweight, unresolved, substitute, suppressed, or missing
occurrence, the rule skips that occurrence only while constructing browser order. Any
document that Inventor has successfully resolved is still included in the preview.
– Error messages identify the processing stage, such as collecting referenced files,
building the preview window, or executing the rename plan. Include that stage name
when reporting a problem.
– Resolve missing references in Inventor before running the rule. A file that Inventor
cannot resolve cannot be copied or have its references updated safely.
