The Revit 2022 SDK is now available for download from the Revit Developer Centre, autodesk.com/developrevit.
I logged my experiences installing and compiling it, setting up the RvtSamples application to load all the SDK external commands, and migrating The Building Coder samples to the new release:
ParameterType and ForgeTypeIdIn reality, I migrated RevitLookup first, then The Building Coder samples, and last I installed the SDK and set up RvtSamples. Here are my log files of errors, warnings and WIP notes in that order:
Let's look at the SDK installation first, though:
The first thing I did was update my RevitSdkSamples GitHub repository to the new release, enabling me (and you) to easily track all the changes I made, cf. release 2022.0.0.0 and subsequent ones.
I loaded the SDKSamples.sln solution file and was glad to note that the Revit API assembly references were all set up and ready to go.
The compilation succeeded out of the box and all 196 projects completed.
The compilation generated 49 warnings.
Most of the warnings concern the ever-recurring architecture mismatch issue and can be resolved using my DisableMismatchWarning.exe utility implemented back in 2013 and available from the DisableMismatchWarning GitHub repository.
After fixing those, only seven warnings remain; two were due to missing XML documentation comments, and three missing rule sets. I added two trivial documentation comments and deleted a reference to one of the rule sets.
In the end, four warnings remain that I will ignore for now; actually, I don't even know what is causing them or how they could be fixed:
Microsoft.Csharp.targets cannot be imported again. It was already imported... This is most likely a build authoring error. This subsequent import will be ignored.To set up RvtSamples, I need to do two things:
The first is trivial – adapt its *.addin file appropriately and copy it to the Revit AddIns folder.
The second is mostly a lot more work, fixing up the RvtSamples.txt file to correctly list all the external commands defined by the SDK, specifically the pathname of their assembly DLL and their correct .NET class name.
To help with that, I temporarily turn on a debugging flag that tests the validity of that data by attempting to load and thus test the existence of each external command.
That turned up a few errors, e.g.:
bin path in several VB.NET samples, VB.NET/bin/Debug/ instead of /VB.NET/bin/Infrastructure alignmentsIn the end, all loaded fine:
You can track the changes I made in the GitHub diffs.
After referencing the new Revit 2022 API assemblies, The Building Coder samples compilation succeeded, producing 35 warnings.
Many were related to the obsolete ParameterType class and the FilterStringRule constructor that loses its caseSensitive argument.
We discussed some aspects of the former issue in
the Revit API discussion forum thread
on Revit 2022: ParameterType.Text to ForgeTypeId.
David Becroft summarises the gist of the matter like this:
To create a text parameter, please use SpecTypeId.String.Text.
For context, the ForgeTypeId properties directly in the SpecTypeId class identify the measurable data types, like SpecTypeId.Length or SpecTypeId.Mass.
The non-measurable data types are organized into nested classes within SpecTypeId, like SpecTypeId.String.Text, SpecTypeId.Boolean.YesNo, SpecTypeId.Int.Integer, or SpecTypeId.Reference.Material.
Regarding text parameters that report their type as Number, here's the history:
Definition had a UnitType and a ParameterType.
The UnitType property was only meaningful for parameters with measurable ParameterType values, and a parameter with ParameterType.Text would report a meaningless UnitType.Number value.UnitType property and replaced it with the GetSpecTypeId method.
The behaviour remained the same – a parameter with ParameterType.Text would have GetSpecTypeId() == SpecTypeId.Number.ParameterType property and the GetSpecTypeId method, replacing them both with the GetDataType method.
A parameter with ParameterType.Text will report GetDataType() == SpecTypeId.String.Text.
Side note: The GetDataType method can also return a category identifier, indicating a Family Type parameter of that category.In The Building Coder samples, I made the following replacements:
FilterStringRule constructor last argumentI replaced one call to the NewFloor method by Floor.Create.
It required the conversion of the edge loop container data type, so it was not completely trivial.
That left two warnings about similar deprecated methods that I chose to leave for the time being:
Loading The Building Coder samples via RvtSamples with the external command checking flag turned on revealed that two external commands were no longer defined, since I commented them out due to excessive use of deprecated unit handling functionality that is of little interest any more: CmdParameterUnitConverter and CmdDutAbbreviation. I simply commented them out in BcSamples.txt.
Now RvtSamples loads The Building Coder samples as well:
The changes I made are clearly listed in the GitHub diffs.
I wish you the best of luck and smooth sailing with your own migration efforts.
A nice new little AI application provided by the main professional technical literature publisher, O’Reilly Answers responds to technical questions of all kinds by scanning thousands of go-to books on the subject at hand:
Need a quick solution you can put to work fast? Just ask O’Reilly Answers. It’s an advanced natural language processing engine that instantly scans thousands of O’Reilly titles to find the snippet that can save the day.
At Autodesk, we use Slack quite a bit, so this will come in handy for me.
To use O’Reilly Answers in Slack, type /oreilly-answers followed by a question to scan the O'Reilly content and get the answer.