Before I cover debugging… It looks like the classic UI is still with us. While this is encouraging as a short term solution and not totally surprising, I can’t see it being in Revit 2011 or above. With the API they’ll have to put back the toolbar code. Which means 3rd party developers will have to accommodate both solutions (ribbons, toolbars). Bit of a mess but then again so is the ribbon and I’m sure there will be many happy customers if they give us a choice until the messribbon is fixed.

Debugging in Revit 2010

I noticed from Ed’s post that he’s having problems debugging in 2010. There is nothing worse than having to continually restart Revit when editing standard API commands. Especially if you’re trying to test against a large project. And personally I never liked edit-continue as a solution, particularly if you’re a TDD/ R# fan.

There’s better but more complex solutions but here is a simple approach that allows you to quickly get up and running. The basis of the solution is running your code as a macro. To do this you have to target RevitProxy rather than RevitAPI. The Factory has been good enough to maintain the same namespaces between the 2 libraries. With the following exceptions.

• You can’t implement IExternalCommand.
• Generics aren’t supported so get_Elements(Filter, ICollection<T>) won’t compile.
• No implement ribbon related methods.

So to use this technique you have to provide a certain level of code separation which isn’t a bad thing.

I’ve uploaded a test VS Project and a macro showing how to use it as a Document macro. To do a build/Run cycle if you modify this code you’re have to re-reference the project assembly in the VS project. The project just tests a simple utility class that counts the number of walls. So to debug using this approach. Modify and compile your  assemblies in Visual Studio. Now recompile the macro in VSTA and debug from VSTA. Not ideal but better than nothing.

So how to use this technique?

Create your project referencing the RevitAPI assembly as normal. Now create a second project in the same solution . This is the assembly that will be used in the macro and subsequent debugging.

In this second project add a reference to the RevitProxy assembly.

Create your classes in the standard API project. Then the crux of this approach is mirroring these classes in the RevitProxy project. To do this go to the RevitProxy project and add the class by adding it as an existing item:

Then reference the file as a link rather than copying the file.

So what you should end up with is 2 projects that mirror the same classes you wish to debug.

Now fire up Revit 2010 and create a macro. Add a reference to the RevitProxy referenced assembly and implement the relevant code using your classes as you would in a RevitAPI command.