revit-ifc: the open source behind Revit's IFC support

The IFC add-in that ships with Revit, with the source published

revit-ifc is the .NET code that Revit and Revit LT 2019 and later use to support IFC. The README states that the open source version overrides the standard version shipped with Revit and its updates, and that the repository contains the source for Link IFC, IFC export and the IFC export user interface. It also says the code works to improve Navisworks import.

That last sentence is the one to read carefully, because it describes an effect on a second product rather than a feature of this one. Revit's IFC support is a real product feature with real constraints, and the published source is the code behind it rather than a separate tool that talks to Revit over an API. The practical implication is that anyone who wants to change how Revit exports IFC has a supported way to do it, at the cost of working inside Revit's own plugin and add-in model.

The repository layout matches that. Source holds the code, Install holds the deployable payload, VSProps holds the Visual Studio property files, and Revit.IFC.sln is the solution you open. The default branch is master, but the working branches are per Revit release, and the README is explicit that you must use the branch for your Revit version, giving Release_27.x.x for Revit 2027 as the example.

The project has been running since Revit 2019, and the release history shows the annual cadence: IFC_v27.0.1 for Revit 2027 on 2026-04-09, IFC_v27.0.1.1 on 2026-04-22, and IFC_v27.3.0.12 on 2026-08-13. The last push was on 2026-09-23.

Only the newest annual version and two before it get fixes

The support policy is stated in one line in the README, in bold, and it is the constraint that should shape your plan. The most current annual version and two previous versions are supported with fixes and changes. Older versions are not.

In practice this means three Revit years. If you are on Revit 2024, you are supported today and for two more annual releases, and then the branch stops receiving changes. That is a reasonable policy for a codebase that tracks a proprietary application whose internal APIs move every year, but it means a firm running a mixed Revit estate has a recurring integration task: rebuild, retest and redeploy the add-in whenever the estate crosses the support horizon.

The release naming carries the Revit year in it, IFC_v27.3.0.12 meaning the 27 series, that is Revit 2027, patch 3, build 12. Patch numbers inside a release series, .12 after .1, indicate that these are hotfix builds for a specific annual version rather than a semver line that evolves across years.

Downloads are distributed through the GitHub releases page, and the README notes that new versions of the addon from 2023 onward should also be available in the Autodesk Desktop App, depending on your user and licence settings. That second channel matters for administrators, since it means the add-in can arrive through the Autodesk update path rather than by manual download, and a firm with managed updates does not need to distribute the DLLs itself.

Building Revit.IFC.sln against your own Revit DLLs

The build is a Visual Studio project, not a package. The README walks through four steps. Open the solution in Visual Studio, pick the branch matching your Revit version, and point the project at your Revit installation, whose default path is:

     C:\Program Files\Autodesk\Revit 2027

Those references are plain DLL references into the installed Revit, which is why the path has to be correct on every machine that builds. NuGet packages are restored by Visual Studio automatically, and if that does not happen the README gives the manual route through the Package Manager Console:

     Update-Package -reinstall

After that you select a configuration, Debug or Release, and a platform, Any CPU, and build the solution from the Build menu, checking that it completes without errors.

Two observations about this setup. First, there is no build script, no CI configuration described for local use, and no cross-platform path: the build assumes Windows, an installed Revit, and a Visual Studio installation with the .NET workloads matching that Revit release. Second, the Any CPU platform label is a little misleading for a plugin that loads into a single process, but it is what the README specifies for both configurations, so it is the setting to use rather than a specific x64 target.

Because the compiled output is a set of DLLs that Revit loads as an add-in, the build is only half of the deployment. The next section covers the other half.

Attaching a debugger to Revit.exe and the add-in bundle path

To inspect the exporter at runtime you build in the Debug configuration, copy the resulting DLLs into the add-in folder, and then attach Visual Studio to the running Revit process. The default add-in location for Revit 2027 is:

     C:\ProgramData\Autodesk\ApplicationPlugins\IFC 2027.bundle\Contents\2027

The debug sequence the README describes is straightforward: start Revit, use Debug and Attach to Process in Visual Studio, pick Revit.exe from the process list and attach, then set breakpoints in the relevant source files. It names the two entry points you are most likely to want, the ExportIFC method in Exporter.cs and the ImportIFC method in Importer.cs, and it tells you to trigger the code path by exporting or linking an IFC file in the running application.

The caveat sits in the same list. For IFC import, much of the logic is processed internally by Revit and is not open-sourced. That single line defines the boundary of this repository. The export path is inspectable and modifiable in source, while the import path in Revit is closed. If your work is on import, for example diagnosing how a link is resolved, you will be reading around a closed implementation rather than inside it.

The project also ships an Install directory, which is the deployment payload for the add-in bundle, and VSProps with the shared property files, so the folder you copy DLLs into is a known quantity for a given branch rather than something you have to reverse engineer.

LGPLv2 source with a proprietary Autodesk DLL inside the build

The licence needs two sentences rather than one. The README states that the Revit IFC open source uses the Library General Public License version 2.0, that it relies on ANTLR 4 which uses the BSD licence, and that it also includes Autodesk.SteelConnections.ASIFC.DLL, a proprietary file owned by Autodesk and licensed under the Autodesk Terms of Use.

Using that DLL means agreeing to the Autodesk Terms of Use and the Autodesk Privacy Statement, and the README is explicit that you may only use it with the Revit IFC open source project. It is provided as-is. So the repository is not a single licence: the code around it is LGPLv2, the grammar tooling is BSD, and one binary component is proprietary with a use restriction that ties it to this project.

For an internal team working on Revit integration, that mixture is usually workable, because you are using the DLL exactly as the project intends. For a team that wants to lift the IFC export logic into a separate product, the boundary matters, and the README does not describe any way to substitute a different implementation of that component.

The licence field shown by GitHub for the project is not recognised as a standard licence, which is consistent with a repository that carries mixed terms and includes a proprietary binary. Read the licence file rather than relying on the badge. Note also that LGPLv2 places obligations on you when you distribute a modified library, which is a different question from running the add-in inside your own licensed Revit installation, and the difference is worth being clear about before you redistribute anything.

Issue triage built around version, component and status labels

The contribution process is unusually well specified for a plugin, and the mechanism is labels. When you file an issue you choose between three templates. The Problem Report covers a bug or error found in any aspect of the IFC functionality, the Enhancement Request covers a proposed change to functionality, user interface or experience, and the Inquiry covers a question about functionality or user interface that is neither of the other two.

The label taxonomy is three dimensional. Version labels identify the Revit year, starting at 2024, 2023 and 2022 and expanding as more versions are released. Component labels identify the area, and the list is API, coordinate system, documentation, export, geometry, GUID, IFC mapping, import, parameters-properties, performance and UI/UX. Status labels, set by the Autodesk developers rather than the reporter, are Rejected, In progress, Cannot reproduce, Duplicate, Feedback, Fixed and Triage. The guidance is that each report should carry a version label and a component label from the person reporting, and the developers verify and correct the labels and add the status.

The rationale the README gives for the labels is a fast triage and prioritisation process, with the note that labels let the team group, sort and prioritise issues. It also explains that a report can carry an internal Autodesk Jira number for tracking, which is not visible to the public.

For a project that only supports three Revit years, this triage discipline is the mechanism that decides which of the many possible fixes land in a given annual release, and it is also the only channel you have to influence it.

Editorial conclusion

revit-ifc suits Autodesk customers who need to see, patch or extend the IFC behaviour of Revit, and it suits everyone else poorly, since it is a Visual Studio project bound to a specific Revit version rather than a library you can call. Before building, check that a branch exists for your Revit year, since the support policy keeps only the current annual version and two previous ones, and read the licence file, because the source is LGPLv2 while the bundled Autodesk.SteelConnections.ASIFC.DLL is proprietary and usable only with this project. If your need is to export IFC from a model rather than to work on Revit itself, the exporter already shipped with Revit is the lower-risk path.

Frequently asked questions

Official sources

1. Autodesk/revit-ifc on GitHub
2. Issues
3. README
4. Releases