BOLT OUT OF THE RED

Multi-core scaling of the Revit Database

Guy Robinson — Mon, 01 Feb 2010 13:40:26 +1300

On a fairly regular basis I’m asked questions along these lines:

“We’ve been asking for multi-threaded Revit for years. How hard can it be? <Insert usual ADSK expletive>…”(1)
“Why doesn’t Revit utilise all my PC’s cores like <insert application>…”
“Revit isn’t a real database, and it’s slow according to our DB expert…(2)”
“If ArchiCAD can use multiple cores then there should be no reason Revit can’t do it.(3)”

These questions and Intel’s press release on their 48 core processor has prompted this post in an attempt to explain why I believe it is a difficult Software engineering project to make Revit performance scale with multiple cores.(4)

Do I think we’ll get a measure of scaling eventually? Yes. But it will probably happen progressively and with caution.

What is a database?

I’ll leave it to Wikipedia to describe in detail. I’m going to deliberately try and explain the problem without using computer science . However ;-), to set the scene…

Simplistically, a database comprises 2 major areas of functionality.

Transactional Storage. The ACID properties of the distributed Revit database and other aspects of database storage I don’t intend to discuss.

Querying. This is the aspect of the Revit database that effects the user experience the most when it comes to performance. Querying is used by an application for reading and writing/ updating of a database.

It is the querying of the Revit database I’m going to discuss in this post.

Setting the scene

All the features Revit users take for granted such as :

A window moving with it’s host wall when the wall is moved.
A wall locked to a grid moving with the location change of the grid.
A view title on a sheet updating when the view is renamed

They all are based around a single principle of a defined relationship. Take for example a window hosted by a wall. This can be represented as such:

Keep this in mind as I build up a picture of the problem Autodesk have with querying the Revit database with a multi-core architecture.

Doing some work

Say you have some work to do. There are 5 discreet tasks that can be represented as follows:

At the moment you are on your own, so you start with one and after finishing that you move onto the next one. But it’s too slow. The boss wants to speed things up so he brings in more people to each do a discreet task (5):

The boss is happy but he notes four of the workers are sitting there twiddling their thumbs waiting for the slowest task to finish so they can go home. So he splits that slow task up into discreet subtasks and gives the other workers one subtask each to do:

There’s some extra work required combining the discreet subtasks back together in a coordinated way which costs some time but overall the tasks are all completed in considerably less time.(6) Everyone goes home happy…

The Revit taskforce

The boss gives the workers some new tasks. However, these tasks are no longer discreet, each task depends on some aspect of another task:

In other words each task has a relationship to another task.

So no task can be completed independently by a worker without coordinating and communicating with another worker. This coordinating takes planning,time, and a task may not be completed if the dependent task fails. More critically, throwing more workers at the tasks may not have the desired effect because they’ll spend more time communicating than doing any work on the task.

This in a nutshell is the problem for Autodesk with Revit. Except it looks more like this:

Each task has multiple relationships to other tasks . So where do Autodesk start when throwing more workers at the tasks? Critically you don’t want to be doing a task more than once. And some tasks will be a priority in some contexts and not others. Revit has to manage this and work out the best route to finishing updating a project as quickly as possible. Put simply this is a massive mathematical and computer science project on many levels.

Do Autodesk have the resources to solve this problem? Yes.

Will they succeed? Sure.

Will it happen overnight? I doubt it.

Will they achieve a linear scaling of performance for n-cores? No, for reasons that I described above.

So the next time someone asks, I hope this post goes someway to helping you explain why it’s so difficult for Autodesk to scale Revit for multi-core CPU architecture.

Notes:

(1) Revit is multi-threaded but it doesn’t scale linearly with multi-cores across all areas of functionality. Some functionality and rendering will use multiple cores but the improvement will be barely noticeable for now ( with the exception of rendering).

(2) Revit is not built on a relational database object model. More like a object database model with some similarities to source code systems like CVS for replicating changes.

(3) The details would take another post but I don’t consider archiCAD a true BIM application. It took Revit for people to realise Buildings were designed by multi-disciplined teams and therefore a coordinated Building model for ALL disciplines would be the game changer that we now think of as BIM. One of the core differences between Revit and archiCAD can be explained by the principles discussed in this post.

(4) I have no access to the source code (obviously), I have had no discussions with the factory on this post. But I think I have an understanding of the issues they’re facing.

If you’re part of the DB team in the factory, please don’t laugh too loudly ;-)

(5) This is equivalent to raytrace rendering, video encoding etc where each thread can handle a discreet task and therefore you get close to n-core scaling.

(6) Simplistically this is what we get now with some aspects of Revit functionality.

Happy New Year – Custom Ribbon Tabs Complete

Guy Robinson — Fri, 08 Jan 2010 13:30:44 +1300

As anyone who tried the Christmas ribbon solution would have found, it lacked one feature. The ability to handle context switching between standard projects and families. Changing to the other project type would cause the custom ribbon tab to disappear. There are a number of approaches to handling this context switching.

Brian left a comment on the original post and others contacted me privately to highlight the problem and ask how it can be solved. To make it easier for people I’ve updated the RibbonService class to automatically handle the context switching as per standard behaviour. Hopefully this will also help those coding a more customised solution.

Using the updated RibbonService requires one additional line to bind Revit’s ControlledApplication object to the RibbonService as follows:

     public IExternalApplication.Result OnStartup(ControlledApplication application)

       {

          try

          {

              // Create User tab and get a revit panel

              RibbonService.BindControlledApplication(application);// additional line required

              var tab = RibbonService.CreateTab("RED_ID", "Merry Christmas", true);

              var panel = RibbonService.CreatePanel(tab, "Presents");

Note I updated the namespaces so you’ll have to update your Revit.ini accordingly.Source and binary can be downloaded here . Enjoy!!

Merry Christmas – Ribbons,tabs and Panels

Guy Robinson — Mon, 21 Dec 2009 14:53:46 +1300

It’s that time of the year, so why not finish with a post on what has probably been the most controversial aspect of the Revit 2010 release, the ribbon. In general I’ve stayed clear of UI customisation because I’d prefer Autodesk get it right. However, for API users the ability to add a tab for their own commands has been on the wishlist since the ribbon went live. Jeremy talked about it here with the limitation you couldn’t run API commands.

Using a little smoke and mirrors it is possible however to run API commands. The key is creating a Revit ribbon panel not a base Autodesk panel. This then allows you to use all the standard constructs for creating buttons and therefore running API commands when the button is clicked.

The code is very similar to creating buttons using the standard API’s.

     public IExternalApplication.Result OnStartup(ControlledApplication application)

            {

                try

                {

                    // Create User tab and get a revit panel

                    var tab = RibbonService.CreateTab("RED_ID", "Merry Christmas", true);

                    var panel = RibbonService.CreatePanel(tab, "Presents");

                    ...

RibbonService.CreateTab(…) creates your custom tab. You then add a Revit panel to this tab using RibbonService.CreatePanel(…) . Once you have the panel you can add buttons as per the standard API.

Although this is using standard API’s and has been reliable for sometime now, in publishing this code I need to add the standard disclaimers:

If it crashes/ corrupts your projects it’s not my fault.

If you have problems using this code don’t expect Autodesk to support it.

If it causes your computer to catch fire, it’s not my fault.

If it causes your partner to attack your car with a golf club leading to you crashing into a tree, it’s not my fault or anything to do with my code or Autodesk’s ;-)

I’d also add, don’t abuse this. If Autodesk start seeing every person and their dog adding a tab for 1 or 2 commands they’ll have good justification to shut this down. I see this only been used by inhouse developers wanting to create a company tab or 3rd party developers with numerous commands which they want to aggregate on a single tab.

Source and binary here , enjoy!! Merry Christmas and a happy new year. 2010 is going to be a great year to be a Revit user I think…

Doing it all in Families

Guy Robinson — Thu, 08 Oct 2009 16:23:14 +1300

is not always the correct approach.

It’s been too long since my last post. My blogging time has been occupied by more personal projects, some of which I’ll post about soon (famous last words ;-) ).

I’m always keen to hear from people pushing Revit. In this case the person has immense knowledge of the Revit family editor and some knowledge but no real experience of the API. As required in their jurisdiction, when scheduling windows and doors they have to schedule areas of natural light. These exclude frames and mullions and have to be a percentage of the room area. In other words the visible glazing area per room. Here is the schedule in the test project. Glazing area is just the windows width*height. Natural light area is the glass area and Percent Natural light is (Natural light area/ room area)%.

The first issue they faced is you can’t schedule room area in door and window schedules. Strange, because you can schedule volume but using this and relying on unbounded height to get the area is not a reliable solution. So this is having to be manually entered. AAGH!!!!

The second issue and really the basis for this post is that of calculating the area of natural light. Their solution was to add reference planes and width/height parameters to the window family to define each extrusion representing the areas of glass. And then use these values from the width/height parameters to sum the areas of glazing. Straightforward, except when the window in question looks like this:

This resulted in 25 parameters and an ungodly array of formulae. I totally understand why they have taken this approach. For many the API is like a foreign language and so they have to push the family editor to achieve the desired result. They’ve used best practice techniques for building families and on the face of it , it all looks good. However, this is so not the path BIM and Revit should be taking you down.

Oh dear…

From a Revit development perspective it shows how much there is left to do with the family approach to component creation and management. From an API perspective it shows how inaccessible it is for most, particularly when it is a much better tool for the job as in this situation. Developing and testing this family has been a lot of work, and that’s just the one family. For every different style of window they’re going to have to repeat the process.

Here are the main issues as I see it are:

1.. 25 parameters in one family is a serious documentation and maintenance issue in one family. In a whole series of window families it’s a potential nightmare as you are repeating the formulae in every different family. It also has the potential to be a performance hit in a project of any size.

2.. Yes you could use nesting, but it doesn’t really help much. You still need to aggregate the areas, and you still have the maintenance issues.

3.. Every window series that is different requires a new array of formulae. There is a high risk of someone changing a formula in one family and not updating all associated families. What if you want to use the window in a different jurisdiction and a possibly different approach to calculating the area of natural light? Localisation becomes a problem.

4.. Code compliance analysis has no place in Revit families. Natural light calculations are not specific to the design of the window but rather a generic rule applied to all windows in a project. In software programming this is referred to as separation of concerns. Applying/adding or modification of compliance rules should not require touching the Revit family at all in an ideal world.

The API approach

So how can the API help?

The first thing to do is automate the room area updates. Next is to remove the requirement for customising window families to calculate glazing areas. We can use the API to automatically calculate the natural light areas (glass) from the family geometry. This obviously changes with family type so we need to account for this.

Find attached a 2010 Revit project with a VSTA document macro embedded which does all this. In a production situation I’d use a standard API command, but for this prototype a VSTA macro is adequate.

The approach I’ve taken is to extract the area of glass from the extrusion for the types used in the project. To do this we need to know which geometry is glazing. We could have used the material but they tend to vary within projects and families can have multiple glass materials in one family. Instead the macro looks for extrusions with a glass subcategory.

To get at this subcategory requires editing the family as category isn’t exposed by getting the windows instance geometry in the project.So this is a 2010 project or above. Not the fastest approach but adequate as the parameters vary by window type only. You’d only need to run the macro whenever :

1.. A new window type is used in a project.

2.. The width/height of the window type change.

3.. The room area changes. (This update could be a separate command)

To get the actual glazed area in a family type we check for extrusions which have a subcategory equal to ‘glass’

     if (e.Category.Name == "Glass")

        {

            var GeomM = e.get_Geometry(_geomOption);

            foreach (var img in GeomM.Objects)

            {

                var ss = img as Solid;

                var fc = ss.Faces[0];                                  

                nlArea += fc.Area;

            }

        }

Not a very robust solution for production but good enough to show the point. The beauty of this approach is it works for round or unusual shaped windows without any complexity being added to the family to calculate the area. The issues as prototyped include:

1.. Faces[0] assumes the extrusion has been built in elevation.

2.. the modelled boundaries of the glazing can’t extend into the window frame or mullions. Or the areas will be wrong.

3.. It assumes only one glazing subcategory. Probably ok in most situations.

I’ve documented the code but if there are any questions please add a comment.

Revit Project : Natural Lighting Calculations.rvt

Debugging Commands in Revit 2010

Guy Robinson — Fri, 12 Jun 2009 16:31:00 +1300

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 ~~mess~~ribbon 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.

Grow up Autodesk…

Guy Robinson — Thu, 07 May 2009 16:40:43 +1300

How incredibly childish Autodesk. A very experienced AU speaker and organiser dropped because he had the audacity to question decisions…

Thank you though, it makes my comments in this post all the more pertinent. Looks like the headless chickens are still out of their cages…

For Phil I have one word, bugger…

Maybe everyone just needs a holiday ;-)

Revit 2011 - the most significant release EVER

Guy Robinson — Thu, 07 May 2009 01:25:17 +1300

Yes I have taken my medication and no, I have no crystal ball or prior knowledge ;-) I’ve generally stayed out of the debate over the ribbon UI in Revit 2010. However, this post says too much about Revit development within Autodesk to go unchallenged. No, I’m not saying “if they don’t fix the ribbon in Revit 2011 the world will end”. The issues I’m going to discuss are considerably more fundamental than that…

Nicolas is right when he said the old UI was not scalable to support future functionality. In particular, if and when they produce a single building modelling application a ribbon could be a useful tool in presenting discipline contextual UI’s from a single application.

What got me with the whole ribbon debate was the result didn’t reflect the rigorous approach to software engineering we know they employ. So what went wrong? Well I think Nicolas provides the answer:

“””We’ve also heard that the most significant barriers to Revit adoption are the availability of trained users and the cost of training new users.”””

“””For these reasons, our focus in developing a new user interface for Revit was on the creation of an extensible UI framework that is easier to learn and to use.”””

I’ll rewrite this to what I think he’s really saying:

“””Attracting new subscribers to Revit was more important than supporting current subscribers. The very subscribers who want an UI that increased productivity and who PAID for it’s development.”””

Nicolas’s statement is a concern on so many levels.

I don’t believe the Factory would have suggested this as a reason for implementing the ribbon as we have it in Revit 2010. Therefore did Autodesk Marketing and Management (AMM) make this a directive as Phil suggested? AMM have NO place in product design. Their role is to guide, not define product design, especially when they don’t understand the current product.
The lack of available trained Revit users can be largely attributed to the incredible rate of Revit adoption within the industry (>350,000) and until recently everyone has been very busy so unemployed trained users were rare. The high rate of adoption also suggests the old UI wasn’t a significant issue for most users. So a new UI shouldn’t have been a high priority and the old UI was very very good for a traditional UI.
On a purely functional level, in my experience training users to document projects to a reasonable level of competence with Revit is considerably faster than any other CAD application . Particularly in comparison with AutoCAD. The difficulty in training new users is communicating and managing the disruptive workflow changes a successful Revit implementation generates and communicating the principles of BIM. Hence the importance of everyone from the top down within a firm being on the same wavelength, something Autodesk could learn from. IMO, Autodesk have done little to help firms in this area. A new poorly implemented UI won’t help here.
BIM , and in particular IPD are currently at a very dynamic stage of implementation within firms. Best practice techniques are changing all the time particularly with large projects in multi-discipline teams. This requires a considerable amount of discussion, experimentation and training not centred around the BIM application itself but the disruptive workflow associated with BIM and IPD. A new UI that is counterproductive to implementing this workflow does not make for happy firms. As this survey suggests. So the cost of training for the current implementation of the UI will be considerably higher than it might have been had they got it right.
To use Revit effectively you need to understand how buildings are constructed. A scary number of CAD users don’t. This can be an impediment to using Revit correctly and also contributes to a shortage of trained users. IPD will help here, a new poorly implemented UI won’t.
Why do Autodesk Marketing and Management (AMM) have so little faith in Revit as a platform that they have to dumb the UI down to attract new users? Let the product designers and engineers within the Factory inspire us with well designed new functionality rather than trying to create the lowest common dominator amongst all Autodesk’s CAD applications. Revit is a blank sheet of paper new platform, let it sing. If firms don’t GET Revit then frankly tough, that’s life and those firms that do will reap the benefits. A new poorly implemented UI won’t help these firms anyway.
The difficulty in moving between Revit and AutoCAD is not the UI it’s the workflow differences in documenting a project using either application. The UI has little to do with it. Because an increasing number of firms have moved to 100% of project documentation with Revit this is even less important. For many, AutoCAD is becoming a legacy application limited to acting as a pipe to consultants not yet on the Revit platform.

Revit 2010

Enough about the UI, Nicolas has a lot more to say :

“””In addition to the new UI, the 2010 release of Revit has some very important enhancements. <snip> Other non-visible investments in the platform…”””

These paragraphs are the understatement of the year.

If you look at the structure of the dll’s in the Revit 2010 program directory compared with say Revit 2008 you’ll see a nice orderly structure. There has clearly been a lot of refactoring of the platform in the last few releases. Taking CurtainGridFamily’s for example, there are now 4 dll’s associated with this functionality. These are:

CurtainGridFamilyDB.dll, CurtainGridFamilyMFC.dll, CurtainGridFamilyUI.dll, CurtainGridFamilyResENU.dll

Guessing I’d say:

**DB contains code directly relating to how curtaingrid’s are stored in the Revit database.
**MFC or microsoft Foundation Classes contain specific code related to how curtaingrids interact with the database, other Revit objects and maybe Display related code (how the grids display in the UI with DirectX) or event handling.
**UI contain code related to how functionality is displayed and how the user interacts with grids. Such as grid settings etc.
**ResENU this contains resources for language specific items. Text strings in dialogs, etc. This will be different for each language release of Revit. However the remaining dll’s will be EXACTLY the same.

What’s does this and the new building at Trepelo Road mean for end users? Well taking a stab at it I think we can make the following conclusions.

This explains the relative dearth of new functionality since Revit 2008 because this would have tied up a considerable resource, as well as the best developers in the Factory.

Revit 2010 and the move to DirectX accelerated graphics represents the completion of an overhaul of the Revit platform by a now significantly expanded team at the Factory (Revit.com was approx. 25 developers I think). This overhaul will provide the Factory with many advantages in their approach to software engineering and product design. Including at the very least:

The Revit platform now has all the infrastructure in place to allow a significantly faster rate of development than we have been seeing in the last 3 releases while maintaining a stable , easily managed code base. Revit application stability being a high point currently.
Autodesk can protect it’s IP because not every developer needs to understand how Revit works at the database level. So they can throw more developers at Revit features without worrying if they’re going to run off to Bentley.
Code separation allows individual features to be developed with less impact on the rest of the application. This should help reduce testing and improve code quality.
The guru’s who work on the database can be left alone to research the big ticket items (WAN, n-core scaling etc) while the rest of the team works on adding new functionality oblivious to how that data is stored. Likewise UI experts can concentrate on the UI. Happy productive teams…
UI design could be discipline/ geographically unique while the backend code remains the same stable tested platform. UI changes can be made quickly without massive testing of the backend (hint: ribbon).
A single building modelling application with discipline specific analysis extensions is SO SO achievable now it’s got to be a given. It’s just when… If you think Revit will be just Arch/Struct/MEP in future then I think you’re dreaming.

All in all the next few releases should be an exciting time for Revit users. So why will the 2011 release be so significant?

The whole UI debacle in Revit 2010 as discussed above and how they respond.
The Factory is now a much larger team, new members (as I understand it) have largely come from the ADT team given that product is on it’s last legs. IMO though ADT is a piece of crap. I hope they are open to a new platform and understand what Revit should represent and this has been communicated. Not what some myopic AMM’s think a Autodesk BIM product should be or how it worked in AutoCAD. And this new team is given the independence to make and justify their decisions without AMM rocking the boat as they clearly seem to have with the ribbon.
The Factory is now a much larger team. Communication within teams will be more difficult. Ensuring Revit remains a cohesive BIM application that inspires users with new functionality that is not just ports of AutoCAD or ADT principles will be a difficult task. One that won’t be helped if AMM don’t understand the product or philosophy.

On many levels Revit 2010 can be thought of as the first major Autodesk release of Revit. There is probably not a line of code now that hasn’t been touched by Autodesk developers within this new platform. The next major release will be the first indications of whether this new platform and team is delivering. It’s a credit to the team though that the transition has gone so smoothly to date.

Certainly the process will be dynamic and the team will make mistakes but IMO the ribbon implementation was not a good first step. And if you want a clear indication that this team can get it right? Just look at the new API calls in Revit 2010. The Factory was undoubtedly left alone to define their product as they saw fit and they delivered.

What needs to happen?

Hopefully Autodesk Marketing and Management (AMM) don’t panic. This statement from Nicolas is concerning:

“””We’re already planning for ways to incorporate the current wish list items in the next release of Revit.”””

Well isn’t that a given… shouldn’t that have been happening ALL the time? The very presence of his post and the new email alias also suggests they’re panicking somewhat. The worst result for Revit 2011 would be AMM run around like headless chickens and force the Factory to make the priority for Revit 2011 quantity over quality of new features.

There is a good argument to suggest what is needed next is a few easily implemented long standing requests and a considerable amount of work going into fixing the pages of issues with current functionality that has been ignored since their inception. However for a AMM that likes big ticket candy this is a harder sell to the shareholder and press.

Conclusion

Revit currently, remains the only released building modelling application both within Autodesk or externally, that has any hope of realising the promise of BIM and IPD that all the powerpoints from AMM suggest is possible, and the building industry dreams of.

From my discussions with people in the Factory, and from stellar releases such as the Revit 2010 API enhancements its clear at least at the micro level they have the ability and platform to deliver the goods. However, it’s also clear from debacles such as the Revit 2010 ribbon UI implementation that at the macro level there is still much that needs to change within Autodesk and their approach to Revit product development.

Current users of Revit just need to wait and hope they let the factory do their job.

So it’s for these reasons and what we get with the release of Autodesk Revit 2011 that will tell us whether anything has changed, and why it will be the most significant release of Revit EVER…

Restarting…

Guy Robinson — Wed, 06 May 2009 12:47:02 +1300

Thanks for the concern from those that were worried ;-) I haven’t disappeared off the face of the earth. Very busy and school holidays in Wanaka.

Then very nasty stomach bug went slowly through our whole household. Normal transmissions about to restart…

A significant milestone

Guy Robinson — Wed, 01 Apr 2009 17:07:38 +1300

After a considerable amount of work I’ve finally managed to complete what is by far my most significant Revit API command to date. In trying to figure out what would attract AutoCAD users to Revit I hit upon what I consider to be the missing link. This command will also be very useful for Revit experts.

Utilising JAVA for crossplatform support, OpenGl, .NET, WCF, AJAX, WPF, REST and a little bit of a cloud database platform I’ve implemented a distributed natural language commandline for Revit. That’s right a commandline for Revit!!! Here’s a screen shot:

The Revit 2009 application is here. All assemblies must be in the same directory. Note it’s a command application not an external command and it adds a Redbolts menu rather than adding an entry to external tools. And sorry no source code for this one. The intellisense has a bug at the moment so you’ll have to get the syntax of your queries right. I’m just so excited I couldn’t wait to get this out for you to try. Here’s some examples of syntax and some queries to try.

Please return all walls with width < 4000mm

Please sum all window areas on level 1

Please return all rooms with external doors

You must start a query with please , I needed a trigger string for a query and this seemed a polite option;-)

Enjoy, and any questions please leave a message or send me an email.

Load() that command please?–User settings Part 4

Guy Robinson — Fri, 27 Mar 2009 15:04:07 +1300

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..

When an Appdomain tries to load an assembly it first looks in the GAC and the directory defined by it’s ApplicationBase property. Normally this is the directory of the executable and this is the case for Revit. You can also add subdirectories of the ApplicationBase directory, by setting the privateBinPath via the AppDomainSetup and the Domain manager will look there as well. Unfortunately this can’t be set once Revit has started so how do we make the Revit AppDomain load our command assemblies into the correct binding context?

I should also add, you may additionally require FullTrust if the command is loaded from a network path

Every AppDomain has by definition one configuration file. In our case this will be Revit.exe.config which resides in the Revit executable directory .In Revit 2009 you need to create this yourself, in the executable directory. In Revit 2010 it is already created because Autodesk are configuring a CAS setting for the CLR. You’ll see from the documentation on the configuration schema and in particular the runtime schema that there are 2 solutions that allow us to ensure our commands are loaded correctly by the Revit AppDomain.

Probing Solution

Probing will add subdirectories to the PrivateBinPath, ensuring any command assembly in these subdirectories will be probed correctly and load in the Load() context . Paths can only be subdirectories of the Revit program path not full paths outside of the ApplicationBase directory.

The advantage of this solution is it very easy to configure. It’s great for development, as long as you place the command assembly in a configured subdirectory the command will load into the correct binding context. The disadvantage is it won’t work if you want to place your command assembly on the network.

The following is an example Revit.exe.config file. In this example we’re defining 2 subdirectories to be added for probing. For a default XP installation the full paths to these directories would be :

C:\Program Files\Revit Architecture 2009\Program\Extensions
C:\Program Files\Revit Architecture 2009\Program\Extensions\Dev

     <?xml version="1.0" encoding="utf-8" ?>

    <configuration>

        <runtime>

            <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

                <probing privatePath="Extensions\;Extensions\Dev;"/>

            </assemblyBinding>

        </runtime>

    </configuration>

Note all subdirectories need to be defined by separating paths with semi-colons (;)

CodeBase solution

This solution is the most exact but also requires the most configuration. You must provide the complete codebase for the assembly in question. This is most useful when you want to store command assemblies anywhere on the network. The assemblies full Identity must be included or this solution will not work. It is not enough to just provide the codebase. The full path and version of the assembly is provided and at a minimum the assembly's name. The following is an example Revit.exe.config:

    <configuration>

        <runtime>

            <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

                <dependentAssembly>

                    <assemblyIdentity name="MyCommand" />

                    <codeBase version="1.0.0.0" href="FILE://C:/2009Commands/MyCommand.dll"/>

                </dependentAssembly>

            </assemblyBinding>

        </runtime>

    </configuration>

Note the following:

The format of the href with the FILE prefix as per standard URI’s.
You must add an assembly binding entry for each command assembly you want to load.
If you version your assemblies then the version property of the binding must be updated accordingly.

For both solutions you must add these AppDomain configuration settings to the Revit.exe.config file not your commands app.config file.

So that’s how we can use any .NET assembly in our commands. Now we know how to do this I can complete the series by explaining how to implement a fully featured configuration solution in your commands.