Learning from RevitLookup for install, GitHub actions, builds, releases, etc

[harrymattison]

There has been a lot of very nice work by @nice3point @ricaun and others to set up the build/install/release scheme for RevitLookup. Is there any documentation or advice on how to leverage that for other Revit plug-ins?

For example, I have this Github Action that builds Revit 2023/2024 on a windows-2019 runner, and also builds 2025 on an windows-2022 runner (which seems necessary because of the .net version differences) but then the files are on two different machines and can't be put all together for the installation. And then there are questions about how the best way to create the Github releases. Can https://github.com/velopack/velopack be added to automatically detect and install updates?

My sense is that https://github.com/ricaun-io/ricaun.Nuke.PackageBuilder and other packages have already figured all this out and it would be a big help to not have to reinvent the wheel. Thanks for any advice!

name: Build 2023 2024
on: [workflow_dispatch, push]
jobs:
build_2023_2024:
runs-on: windows-2019
steps:
- name: Checkout
uses: actions/checkout@v2
- name: Setup MSBuild
uses: microsoft/setup-msbuild@v1
- name: Setup NuGet
uses: NuGet/[email protected]
- name: setup-msbuild
uses: microsoft/[email protected]
- name: Restore Packages
run: nuget restore MyTestApp.sln
env:
NUGET_RESTORE_MSBUILD_ARGS: /p:Configuration=2023
- name: Build solution
run: msbuild MyTestApp.sln -t:rebuild -property:Configuration=2023
- name: Restore Packages
run: nuget restore MyTestApp.sln
env:
NUGET_RESTORE_MSBUILD_ARGS: /p:Configuration=2024
- name: Build solution
run: msbuild MyTestApp.sln -t:rebuild -property:Configuration=2024
build_2025:
runs-on: windows-2022
steps:
- name: Checkout
uses: actions/checkout@v2
- name: Setup MSBuild
uses: microsoft/setup-msbuild@v1
- name: Setup NuGet
uses: NuGet/[email protected]
- name: setup-msbuild
uses: microsoft/[email protected]
- name: Restore Packages
run: nuget restore MyTestApp.sln
env:
NUGET_RESTORE_MSBUILD_ARGS: /p:Configuration=2025
- name: Build solution
run: msbuild MyTestApp.sln -t:rebuild -property:Configuration=2025
advinst-aip-build-demo:
runs-on: windows-latest
name: Build Aip Demo
steps:
- name: Check out repository code
uses: actions/checkout@v2
- name: Build AIP
uses: caphyon/[email protected]
with:
advinst-version: '21.2.2'
advinst-license: ${{ secrets.ADVINST_LICENSE_KEY }}
advinst-enable-automation: 'true'
aip-path: ${{ github.workspace }}\MyTestApp.aip
aip-build-name: DefaultBuild
aip-package-name: setup.msi
aip-output-dir: ${{ github.workspace }}\setup
aip-commands: |
SetProperty FOO="foo"
SetVersion 1.2.0
- name: Publish setup artifact
uses: actions/upload-artifact@v2
with:
name: setup
path: ${{ github.workspace }}\setup\setup.msi

[jeremy_tammik]

Yes indeed, that would make a heck of a nice blog post (series?), wouldn't it?

[ricaun]

---

@harrymattison wrote:

There has been a lot of very nice work by @nice3point @ricaun and others to set up the build/install/release scheme for RevitLookup. Is there any documentation or advice on how to leverage that for other Revit plug-ins?

For example, I have this Github Action that builds Revit 2023/2024 on a windows-2019 runner, and also builds 2025 on an windows-2022 runner (which seems necessary because of the .net version differences) but then the files are on two different machines and can't be put all together for the installation. And then there are questions about how the best way to create the Github releases. Can https://github.com/velopack/velopack be added to automatically detect and install updates?

My sense is that https://github.com/ricaun-io/ricaun.Nuke.PackageBuilder and other packages have already figured all this out and it would be a big help to not have to reinvent the wheel. Thanks for any advice!

RevitLookup is using Nuke.Build to automate the build of the solution in the GitHub action or locally.

That's basically a csharp code that build each configuration of the RevitLookup project, copy the dll files to the installer and create the installation for each version, and releases the installation in the GitHub release when running in the GitHub Action in the main/master branch.

Doing that using the default GitHub action yml would be complicated. In your GitHub action case, you should use only one machine and install the missing target frameworks before running any msbuild.

Like installing the net8.0 using the actions/setup-dotnet

    - name: Setup .NET Core
      uses: actions/setup-dotnet@v4
      with:
        dotnet-version: 8.0.x

Or installing some specific Net Framework using some command tool like NETFrameworkTool.

• https://github.com/ricaun-io/NETFrameworkTool?tab=readme-ov-file#github-actions

After you machine have all the dependencies requires to build you projects you can run some msbuild or execute the 'build.cmd' to execute the Nuke.Build automation to do whatever you want.

In my case the 'ricaun.Nuke.PackageBuilder' is a package with some automation to build each configuration in the project that is not 'debug', get the result and create the '.addin' for each configuration and construct the 'PackageContents.xml' and the '.bundle' folder matching each '.addin' with the correct version of Revit. And than create a simple installation to install/copy the '.bundle' in the machine.
If the automation is running in GitHub action, creates the release when running in the main/master branch, with the installation and the '.bundle' zip folder.

This velopack looks interesting for a standard desktop application, to use for a Revit Addin don't thing that gonna work well. The simple approach basically what RevitLookup does, download the new installation version and execute the installation when Revit closes, so the user need to reinstall the plugin when the new version.
Now if you what some silent update is trickier because you can not replace the dll when Revit is using, in the past I was doing some crazy copy the files to a temp folder and using that copy to be loaded inside Revit, was too complicated.

Today I use the '.bundle' replace approach, using that I can update '.bundle' content with the new version of the plugin, giving support to the new version of Revit if needed. Because the dll is sign Revit gonna load without the popup, and the user can enjoy the update in the next Revit section. Here is some info how that works: https://ricaun.com/update-revitaddin/

If you need help with GitHub automation you can reach me in the Discord:

• https://discord.gg/ahZNySK5hK