Build DynamoRevit from Source
Last updated
Last updated
The DynamoRevit source files are also hosted on the DynamoDS Github for developers to make contributions and build beta versions. Building DynamoRevit from source generally follows the same process as Dynamo with the exception of a few important details:
DynamoRevit references Dynamo assemblies, so these should be built with matching NuGet packages. For example, DynamoRevit 2.x will not load into Dynamo 1.3.
DynamoRevit is specific to Revit versions, for example: the DynamoRevit 2018 branch should run on Revit 2018.
For this guide we will use the following:
Revit 2023
The latest DynamoRevit build on branch Revit2023
The latest Dynamo build
To ensure a successful build we will clone and build both the Dynamo and DynamoRevit repositories to use in this walk-through.
Note: building Dynamo manually before DynamoRevit is only required if you are building Dynamo 1.x and DynamoRevit 1.x - newer versions of the DynamoRevit repository rely on the NuGet package manager for the Dynamo dependencies required to build. While a build of DynamoRevit 2.x does not require pulling Dynamo manually you'll still need the core dlls somewhere else to actually run the DynamoRevit addin - so it's worth pulling and building Dynamo anyway. See more below: Building the repository using Visual Studio
The code for the DynamoRevit project lives in a separate repository on Github from the core Dynamo source code. This repo contains the the source files for Revit-specific nodes and the Revit addin which loads Dynamo. Builds of DynamoRevit for different versions of Revit (2016, 2017, or 2018, for example) are organized as branches in the repository.
DynamoRevit's source is hosted here: https://github.com/DynamoDS/DynamoRevit
Clone or download the repository
DynamoRevit's branches reference Revit versions
In a similar process to pulling the Dynamo repository we will use the git clone command to clone DynamoRevit and specify the branch that matches our Revit version. To get started, we will open a command line interface and set the current directory to the location where we want to clone the files to.
cd C:\Users\username\Documents\GitHub changes the current directory
Replace
usernamewith your username
We can now clone the repository into this directory. Though we will need to specify a branch of the repository, we can switch to this branch after cloning.
git clone https://github.com/DynamoDS/DynamoRevit.git clones the repository from a remote URL and by default switches to the master branch.
Once the repository has finished cloning, change the current directory to the repository folder and switch to the branch that matches the installed version of Revit. For this example, we are using Revit RC2.13.1_Revit2023. All remote branches can be viewed on the Github page in the Branch drop-down menu.
cd C:\Users\username\Documents\GitHub\DynamoRevit changes the directory to DynamoRevit.
git checkout RC2.13.1_Revit2023 sets the current branch to RC2.13.1_Revit2023.
git branch verifies which branch we are on and shows the others that exist locally.
The branch with an asterisk is the one currently checked out. The
Revit2018branch is showing because we previously checked it out, so it exists locally.
It is important to choose the correct branch of the repository to ensure that when the project builds in Visual Studio it will reference assemblies in the correct version of Revit's installation directory, specifically RevitAPI.dll and RevitAPIUI.dll.
Before building the repository, we will need to restore the NuGet packages with the restorepackages.bat file located in the src folder. This bat file uses the nuget package manager to pull built binaries of dynamo core, which DynamoRevit needs. You might also choose to build these manually, but if you are only making changes to DynamoRevit and not Dynamo core. This makes getting started faster. Make sure to run this file as an admin.
Right-click
restorepackages.batand selectRun as administrator
If the packages are successfully restored, a packages folder will be added to the src folder with the latest beta NuGet packages.
The latest beta Dynamo NuGet packages
With the packages restored, open the DynamoRevit.All.sln Visual Studio solution file in src and build the solution. The build may initially have trouble finding AssemblySharedInfo.cs. If so, rerunning the build will resolve this issue.
Select
Build > Build SolutionVerify that the build was successful in the Output window. A message should read
===== Build: 13 succeeded, 0 failed, 0 up-to-date, 0 skipped =====.
Revit requires an add-in file to recognize DynamoRevit, something the installer would create automatically. In development we need to manually create an add-in file that points to the build of DynamoRevit we want to use, specifically the DynamoRevitDS.dll assembly. We also need to point DynamoRevit to a build of Dynamo.
Create a Dynamo.addin file in Revit's add-in folder located in C:\ProgramData\Autodesk\Revit\Addins\2023. We already had a version of DynamoRevit installed, so we will just edit the existing file to point to the new build.
Specify the file path of DynamoRevitDS.dll inside of <Assembly>...</Assembly>.
Alternatively, we can have the add-in load the version selector instead of a specific assembly.
Set the <Assembly>...</Assembly> file path to DynamoRevitVersionSelector.dll
<FullClassName>...</FullClassName> specifies what class to instantiate from the assembly which we pointed to with the assembly element path above. This class will be the entry point for our addin.
Additionally, we need to remove the existing Dynamo that ships with Revit. To do that, go to C:\\Program Files\Autodesk\Revit 2023\AddIns and remove the two folders that contain Dynamo - DynamoForRevit and DynamoPlayerForRevit. You can either delete them or back them up in a separate folder if you need to recover the original Dynamo for Revit.
The second step is to add a file path for the Dynamo core assemblies to the Dynamo.config file in DynamoRevit's bin folder. DynamoRevit will load these when the add-in is opened in Revit. This config file lets you point your DynamoRevit addin to different versions of the dynamo core for developing and testing changes in both core and DynamoRevit.
The code should look like this:
Add the bin folder's directory path to <add key/>
We cloned and built Dynamo right before this walk-through to ensure that it will work well with DynamoRevit. The directory path points to this build.
Now when we open Revit, there should be a Dynamo add-in located in the Manage tab.
Select
ManageClick the Dynamo add-in icon
An instance of DynamoRevit
If an error dialog window appears showing missing assemblies, it is likely that there was a mismatch between the versions of DynamoCore that you built against and the ones you are loading at runtime. For example, DynamoRevit with the latest 2.0 beta packages of DynamoCore will not work if you try to start it using Dynamo 1.3 dlls. Make sure that both repos are of the same version and DynamoRevit is pulling a matching version of the nuget dependencies. These are defined in the package.json file of the DynamoRevit repo.
In the previous section, Build Dynamo from Source, we briefly introduced debugging in Visual Studio and how to attach visual studio to a process. Using an exception in the Wall.ByCurveAndHeight node as an example, we will walk through how to attach to a process, set break points, step through code, and use the call stack to determine the exception's source. These debugging tools apply generally to .net development workflows, and are worth exploring outside of this guide.
Attach to process links a running application to Visual Studio for debugging. If we want to debug behavior occurring in a build of DynamoRevit, we can open the DynamoRevit source files in Visual Studio and attach the Revit.exe process, which is the parent process of the DynamoRevit addin. Visual Studio uses a symbol file (.pbd) to make the connection between the assemblies DynamoRevit is executing and the source code.
Break points establish lines in the source code where the application will pause before executing. If a node is causing DynamoRevit to crash or return an unexpected result, we can add a break point to the node's source to pause the process, step into the code, and inspect live values of variables until we find the root of the problem
Stepping through code walks through the source line by line. We can run functions one by one, step into a function call, or jump out of the function we're currently executing.
The Call stack shows the function that a process is currently running relative to the previous function calls which invoked this function call. Visual Studio has a Call Stack window to display this. For example, if we reach an exception outside of the source code, we can see the path to the calling code in the call stack.
2,000 Things You Should Know About C# has a more in-depth explanation of call stacks
The Wall.ByCurveAndHeight node throws an exception when given a PolyCurve as its curve input with the message: "To BSPlineCurve Not Implemented". With debugging we can figure out why exactly the node won't accept this geometry type as an input for the curve parameter. For this example, we are assuming that DynamoRevit has been successfully built and can be run as an add-in for Revit.
The Wall.ByCurveAndHeight node throwing an exception
Start by opening the DynamoRevit.All.sln solution file, start Revit, and start the DynamoRevit add-in. Then attach Visual Studio to the Revit process with the Attach to Process window.
Revit and DynamoRevit need to be running to show as an available process
Open the
Attach to Processwindow by selectingDebug > Attach to Process...Set
TransporttoDefaultSelect
Revit.exeSelect
Attach
With Visual Studio attached to Revit, open the Wall.ByCurveAndHeight source code in Wall.cs. We can find this in the Solution Explorer under Libraries > RevitNodes > Elements in the Public static constructors region of the file. Set a break point in the constructor of the wall type so that when node is executed in Dynamo, the process will break and we can step through each line of code individually. Usually Dynamo zero touch type constructors start with By<parameters>.
The class file with the constructor for Wall.ByCurveAndHeight
Set a breakpoint by either clicking left of the line number or right-clicking on the line of code and select
Breakpoint > Insert Breakpoint.
With the breakpoint set, we need the process to run through the Wall.ByCurveAndHeight function. The function can be executed again in Dynamo by reconnecting a wire to one of its ports, which will force the node to re-execute. The breakpoint will be hit in Visual Studio.
The breakpoint icon changes when it is hit
The Call Stack window showing the method that is up next
Now step over each line in the constructor until we hit the exception. Code highlighted in yellow is the next statement to be run.
The debugging tools for navigating code
Press
Step Overto run the highlighted code then suspend execution after the function returnsThe next statement to run indicated by the yellow highlight and arrow
If we keep stepping through the function, we will hit the exception that displayed in the DynamoRevit window. Looking at the Call Stack window, we can see that the exception was originally thrown from a method called Autodesk.Revit.CurveAPIUtils.CreateNurbsCurve. Thankfully the exception is handled here so Dynamo did not crash. The debugging process has provided context for the issue by bringing us to another method in the source code.
Since this is not an open source library, we cannot make changes there - now that we have more information we can report the issue with more context by filing a github issue or we could propose a workaround for this issue making a pull request.
When we hit the statement causing the exception in
Walls.cs, the debugging process brings us as close as it could to the root of the issue in the user code insideProtoToRevitCurve.csThe statement causing the exception in
ProtoToRevitCurve.csIn the Call Stack, we can see that the exception is coming from non-user code
A pop-up window giving us information about the exception
This process can be applied to any source files we are working with. If we are developing a library of Zero-Touch nodes for Dynamo Studio, we can open the library's source and attach a Dynamo process to debug the node library. Even if everything is functioning perfectly, debugging is a great way to explore code and find out how things are working.
This process is nearly identical to pulling changes for Dynamo, except that we will need to ensure that we are on the correct branch. Use the git branch command in the DynamoRevit repository to see which branches are available locally and which are currently checked out.
cd C:\Users\username\Documents\GitHub\DynamoRevit sets the current directory to the DynamoRevit repository.
git branch verifies we are on the correct branch, RC2.13.1_Revit2023.
git pull origin RC2.13.1_Revit2023 pulls changes from the remote origin RC2.13.1_Revit2023 branch.
Origin simply points to the original url we cloned.
We want to be mindful here of which branch we are currently on and which one we are pulling from to avoid pulling changes from
RC2.13.1_Revit2023intoRevit2018for example.
As mentioned in Build Dynamo from Source, when we are ready to submit a change to the DynamoRevit repository we can create a pull request following the Dynamo team's guidelines laid out in the Pull Requests section.
