In a typical workflow for deploying Revit products, you may want to include a customized Revit.ini file as part of the deployment. Customizing the Revit.ini allows you to include many settings in your deployment that you might want to roll out. Check out 10 Revit.ini Customizations for some of the customizations you can do with the Revit.ini file. For 2012, we covered a change to the installed location for the Revit.ini file in Who moved my Cheese (Files) ? - Important File location changes for Revit 2012 as well.
For a deployment, the Revit.ini file is created differently than in older releases. In 2011 for example, the Revit.ini is located within a created deployment in a location like: \AdminImage\RevitSetup\RevitArchitecture. You can simply open the ini and make changes to it, save it, and those changes are rolled out as part of the deployment.
In Revit 2012, the Revit.ini file is created on the fly by a inifile.xml file that is included in the deployment. Revit.ini is created at install time using data from this xml document. By modifying that document you can distribute customizations with your deployment.
Identical copies of this document are potentially located in four places in your admin image:
- \x86\RAC2012\Program Files\Autodesk\Root\Program\Setup\Cache\inifile.xml
- \x64\RAC2012\Program Files\Autodesk\Root\Program\Setup\Cache\inifile.xml
Note: Replace RAC2012 with RME2012 for Revit MEP or RST2012 for Revit Structure.
You probably only have two of the copies in your admin image, either x86 or x64.
Copy one of these locally and open it up. You'll notice that inifile.xml updates more than just revit.ini. But you should ignore the other ini files as they affect other install items and don't affect the Revit.ini file.
The elements are structured by a File->Section->Data methodology. Knowing this you are ready to do some easy tasks. You can:
- Change a value by updating an existing Data element
- Add a key to a section by creating a Data element
- Add a section to an ini file by creating a Section element
For example, let’s say we wanted to make sure that Press and Drag is turned off. In the inifile.xml file you could add the following under the Revit.ini file section:
The Section Name key determines the name of the bracket section that will be created in the ini file. The Data Key is the name of the items we are adding to the ini file. Finally, the <![CDATA]> that follows the Data Key is the value that we are setting in the ini file. In the example above, the red 0 indicates where you would change the value.
So adding the above to the inifile.xml as part of a deployment should add the below to your Revit.ini that is created with your deployment:
Let’s try another example. Let’s say that you would like to pick a different default template to use for Revit. Start by looking for the DefaultTemplate Data Key. You will probably find:
<Data Key="DefaultTemplate" Product="RAC">
<Condition>RVT_DISCIPLINE="Architectural" OR NOT RVT_DEFAULTTEMPLATE_CONSTRUCTION</Condition>
You, like me, notice some oddities, like Product attributes and Condition elements, and then the stuff between the brackets [ ]. Oh - and not to mention that there’s a bunch of DefaultTemplate elements in the inifile.xml file.
The bottom line is that you can remove the Product attribute and Condition element and replace the [RVT_DEFAULTTEMPLATE_ARCHITECTURAL] section with something like the below instead to point Revit to your template:
The text in red would be your custom template path. So, your inifile.xml file would now look like the following for that section:
<Data Key="DefaultTemplate" >
Also, you can simply remove all those other default template sections from the file. Inifile.xml serves all Revit products, which the Product attributes reflect. Additionally, each product serves multiple disciplines. In order to point the DefaultTemplate to the correct file we created multiple DefaultTemplate elements tied to specific products, each with a condition that further binds it to the discipline selected at install time. Removing these will allow the path you enter to automatically be the default for your deployment no matter what was picked as the discipline at the time of creating the deployment.
Finally, I'd highly recommend using NotePad++ for editing these xml files. It color blocks the xml coding to ensure that the syntax is correct. http://notepad-plus-plus.org/
XML documents are highly structured. If you goof this one up then none of the ini files it defines will be created. Backup your original inifile.xml that are created with the deployment, just in case. Fortunately the inifile.xml file has a DTD, which is a formatting definition that instructs validation tools on how to check the consistency of a document. To operate on inifile.xml with confidence do one of two things.
- Use an XML editor like Notepad++.
- If you don’t use an xml editor, validate your efforts here.
One final note, make sure that you test your new xml file with an installation and make sure that the Revit.ini file is created as expected and that Revit launches the way you expect. As they say, with great power, comes great responsibility.