As I explained in part 3 if a command fails to run other than in the Revit executable directory, there is a good chance it’s because of the command assembly was loaded into the wrong binding context (LoadFrom() ) by Revit. In this part of the series I’m going to explain how we can fix this so you can place a command in any directory..More...

As I mentioned in part 1 , using the advanced classes in System.Configuration in Revit API commands won’t run out of the box. That’s a bit of a generalisation. With a standard installation of Revit, an API command that is using System.Configuration’s more advanced classes such as ConfigurationSection will only work from one location. The directory of the Revit executable (Revit.exe). On XP32 this is usually C:\Program Files\Revit Architecture 2009\Program . More...

The second solution is the first that takes advantage of the System.Configuration namespace and also the first that will save user scoped settings between sessions. Writing a concrete class that inherits from the abstract class ApplicationSettingsBase allows you to easily create application and user scoped settings for your Revit commands. This is the same approach implemented in Visual Studio’s settings designer. More...

Every well designed application will provide some level of user specific configuration. This is the first part in a series of posts explaining how to do this for Revit commands using 3 different techniques.  Revit commands are assemblies not applications so using standard .NET functionality (ie System.Configuration) has a number of problems. I’m going to start with a simple technique and then cover how to do it properly using .NET. Including why doing it properly doesn’t work and how to make it work. The first solution is simple to use but also the weakest solution.More...