BOLT OUT OF THE RED

Compiling and running .NET4.0 Revit commands

Guy Robinson — Mon, 31 May 2010 14:04:00 +1400

For those of you excited by .NET4.0’s new features and wanting to test Revit commands compiled with .NET4.0, you’re in luck. Before I show you how, a few caveats:

I’ve tested this for a few days. While I haven’t run into any unexplained issues , there are areas of new functionality in .NET4 that can cause a bit of a head scratch.
Of course this is unsupported so you can try submitting a bug but don’t be surprised if Autodesk just laugh at you. In other words, “testing and inhouse development only please”.

How to enable .NET4.0

Assuming you have .NET4.0 installed, to enable .NET4.0 support change the runtime lines in the Revit.exe.config to the following. Note if this isn’t the .NET2 version installed then you need to modify the .NET2 version as required.

<startup useLegacyV2RuntimeActivationPolicy="true" >

    <supportedRuntime version="v4.0"/>

    <supportedRuntime version="v2.0.50727" />

</startup>

The critical line is the useLegacyV2RuntimeActivationPolicy=true. To confirm this is working, create a .NET4 assembly and add the following command.

[Transaction(TransactionMode.Manual)][Regeneration(RegenerationOption.Manual)][DisplayName("Test NET40")][Description("Test NET4.0 test command")]public class Command:IExternalCommand{    #region Implementation of IExternalCommand    public Result Execute(ExternalCommandData commandData, ref string message, ElementSet elements)    {        var uiApplication = commandData.Application;        var application = uiApplication.Application;        var uiDocument = uiApplication.ActiveUIDocument;        var document = uiDocument.Document;        var transaction = new Transaction(document, "test .NET4.0");        try        {            transaction.Start();            var td = new TaskDialog("Test Version4") { MainContent = "Running CLR " + Environment.Version.ToString() };            td.Show();            transaction.Commit();            return Result.Succeeded;        }        catch (Exception)        {            if (transaction.HasStarted()) transaction.RollBack();            return Result.Failed;        }    }     #endregion}

Enjoy!!! Looking forward to seeing some Revit->Windows Phone7 mashups!!

Just to clarify, although you can test .NET4 commands Revit is unusable with .NET4 enabled. It causes Revit to crash as soon as you select a standard command.

RevitAddinUtility x32/x64

Guy Robinson — Thu, 20 May 2010 15:12:00 +1400

Jeremy nicely summed up the issues with the RevitAddUtility.dll . I thought I’d document my solution which uses interfaces to solve the issue. The problem is the loader exception fires before your application can catch it. By using interfaces you can utilise the appropriate assemblies which maintaining a single main application and no file copying.

Depending on which platform you run it on, the console app should utilise the correct assembly. In this example it just prints the names of any revit applications installed.

Here’s the console code for reference.

     var assemDir = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);var current = AppDomain.CurrentDomain;IAddInFactory addinFactory;try{    // assume 64bit is more common now    var addInAssemName = AssemblyName.GetAssemblyName(Path.Combine(assemDir, @"Redbolts.AddIn.AddIn64Factory.dll")).FullName;    addinFactory = (IAddInFactory)current.CreateInstanceAndUnwrap(addInAssemName,        "Redbolts.AddIn.AddIn64Factory.AddInFactory",         false, BindingFlags.Default, null, null , null, null, null);    Console.WriteLine("Successfully loaded 64bit OS version of RevitAddInUtility");}catch (Exception ex){    addinFactory = (IAddInFactory)current.CreateInstanceFromAndUnwrap(Path.Combine(assemDir, @"OS32\Redbolts.AddIn.AddIn32Factory.dll"),        "Redbolts.AddIn.AddIn32Factory.AddInFactory",        false, BindingFlags.Default, null, null, null, null, null);    Console.WriteLine("Successfully loaded 32bit OS version of RevitAddInUtility");}  if (addinFactory!= null){    Console.WriteLine(addinFactory.RevitInstalledApplications.Count());    foreach (string revitInstalledApplication in addinFactory.RevitInstalledApplications)    {        Console.WriteLine(revitInstalledApplication);    }}Console.ReadLine();

And here’s the example app (VS2010 solution) ExampleAddInConsole.zip (44.82 kb) enjoy!!

IFC has no place in your Revit BIM workflow

Guy Robinson — Thu, 20 May 2010 12:40:12 +1400

Steve’s post on IFC and the comments that follow, mirror discussions I’ve had on IFC on numerous occasions. I’m going to be more blunt than Steve though ;-) . Don’t get me wrong, an open interoperability layer is vital for BIM but IFC is not the long term solution. For archiving and satisfying jurisdictions that require an open solution, IFC is arguably the only solution currently, however even then it is an incomplete solution. Good luck opening a current generation IFC model in 20 years or the structural analysis.

Before I continue, I better state some caveats:

I don’t know what Autodesk think of IFC, although they were one of the originators of the project. I have had no discussions with the Factory on IFC support or plans.
What I believe to be the preferred long term solution for model communication is currently not a complete solution .
My main concern here is discussing data exchange during the design phase.

Why IFC is bad

The problem with IFC is it takes a lowest common dominator approach to BIM. So even though Revit has IFC certified importers and exporters there is invariably a loss of data fidelity.

An example of this is the new ‘improved IFC’ plugins Graphisoft have written for ArchiCAD 14 to Revit Structure and MEP . Frankly, this shouldn’t be required if IFC was the solution for interoperability. Yes Autodesk could improve the IFC translators in Revit to improve the ArchiCAD experience. But then in lies the problem, every vendor who has an application that implements IFC has to account for subtle differences in implementation or mapping to their object models . This increases the amount of testing and development required for each and every IFC application that is utilising your IFC files. Not to mention the broken workflow.

The way forward

What is an open standard? I believe Autodesk’s idea of open is a freely available self documenting API as we have with Revit. The fact it’s not a complete API is really the problem. Were all vendors of BIM applications to commit to full open API’s for their applications we would be able to implement lossless interfaces to our 3rd party applications. While this may increase the amount of upfront development, by the use of well designed code libraries this can be minimised. It will have the benefit of significantly reducing testing requirements as well as providing the possibility of a richer user experience more suited to the host vendors application.

Full open API’s are inherently self testing, it would not be a lot of effort to test this for the major BIM vendors. Were 3rd party vendors to commit to open API’s as well, interesting mashups would result further increasing the rate of BIM innovation. Because open API’s are self documenting it allows vendors to innovate rapidly without having to worry about maintaining IFC compliance. This would significantly reduce testing.

Using the existing Revit API as an example, we are now starting to see the benefits of this open API approach. The new solar radiation technology preview for Revit 2011 is an excellent example of a fluid user experience in this case implemented within the Revit UI using the Revit API. Equally the API could be used for direct external communication of object data.

Archiving

Steve summed it up nicely:

“If we don't print stuff at some point in the future for archiving and just rely on it being available digitally everything will have to be saved/stored in some "neutral" format...not just BIM or CAD or doc files etc.”

I don’t see IFC as any more a guarantee for archived BIM projects than a closed Autodesk file format. And regardless of which file format, would a BIM project file be a true reflection of a buildings’ as built state in 20 years time? The only real solution for all data is to serialise it into a human readable format like XML. Entirely possible with a full open API.

A Revit user and don’t agree?

If you’re a Revit user and you don’t agree then you better start searching for an alternative because Revit is living proof IFC plays no role in a fluid BIM experience. Revit Structure and Revit MEP both use direct integration and 3rd party analysis via the API to provide a workflow than would never be possible via IFC. The new solar radiation technology preview for Revit 2011 is just the start. As the API develops we’ll see further examples of direct integration via the API providing an improved BIM and IPD experience over the IFC alternative.

Summary

What will provide a vastly improved experience for architects and all those involved in building design is not better IFC tools from Autodesk and other vendors but a move by vendors to open and full API’s for their applications. And that goes for the 3rd party vendors as well. This would allow lossless data exchange and vastly improved BIM workflows.

So if you want to hassle Autodesk about anything, hassle them about the API and extending it to provide a lossless bi-directional pipe to 3rd party applications. If a vendor is moaning about IFC, tell them to look to the API instead. There is much missing in the current API around element configuration and element creation.

I see a full API as a win-win for Autodesk and end users. They get to concentrate on innovation without having to reveal and document their file formats or trying to convert to a lower common dominator file format such as IFC. The end user gets a framework for rich, interactive applications that will increasingly become required tools for BIM and IPD.

For project archiving, I don’t see IFC as anymore a guarantee than any other solution. A move to vendor supported serialisation of project data along with the appropriate schema would seem to be the only real possibility for lossless rebuilding of projects in the future. Even then, would the model represent the current as built structure? With the current state of the Revit API a certain level of serialisation is possible now. With published schema that mirror the API it would be possible to write rich importers for future versions of Revit or any other BIM application.

In conclusion, while some vendors and countries are pushing IFC, BIM and in particular IPD is still in it’s infancy. A push for software vendors to provide full open API’s to their application would I believe, provide a win-win for vendors and users. So hassle Autodesk about the API and hassle your 3rd party software vendors about the API instead of IFC.

Revit2011 –Compiled SDK for consumption

Guy Robinson — Thu, 29 Apr 2010 11:12:04 +1400

I’ve had some requests for compiled assemblies of the Autodesk Revit 2011 API SDK samples. They’re useful for those of you who don’t have Visual Studio installed or don’t know how to compile them. Or if you’re wondering what’s supplied in the SDK and just what’s possible with the API. This isn’t as user friendly as it could be due to the number of commands, but here’s a download of all SDK samples . The SDK is an impressive resource now.

Note: These are Autodesk SDK Samples . I haven’t tested them all so if you find something that doesn’t work let me know. The API team had a huge job migrating to the 2011 API so I wouldn’t be surprised if some didn’t work correctly at the moment. If it’s an easy fix I’ll update the download.Because they’re Autodesk samples they’re covered by their licence:

Permission to use, copy, modify, and distribute this software in object code form for any purpose and without fee is hereby granted, provided that the above copyright notice appears in all copies and that both that copyright notice and the limited warranty and restricted rights notice below appear in all supporting documentation.

AUTODESK PROVIDES THIS PROGRAM "AS IS" AND WITH ALL FAULTS.AUTODESK SPECIFICALLY DISCLAIMS ANY IMPLIED WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. AUTODESK, INC. DOES NOT WARRANT THAT THE OPERATION OF THE PROGRAM WILL BE UNINTERRUPTED OR ERROR FREE.

Use, duplication, or disclosure by the U.S. Government is subject to restrictions set forth in FAR 52.227-19 (Commercial Computer Software - Restricted Rights) and DFAR 252.227-7013(c)(1)(ii) (Rights in Technical Data and Computer Software), as applicable.

If you’ve installed the samples correctly you should see 5-6 extra tabs (depending on discipline) with all the commands available via the new tabs on the ribbon. MEP and Structure will have an extra tab for commands specific to their disciplines. All other commands should run on any Revit discipline. I have used a generic icon for the button images, hopefully this isn’t too confusing.

Here’s my Revit installation running the SDK samples.

Any files (.rvt,.rfa,.xlsx) relevant to the command are in the files subdirectory. ReadMe files for each command are in the help subdirectory.

To Install Samples

1.. Download the zip (SDKSamples.zip) from here and unpack the zip to the required directory. Remember to unblock the zip if running Win7.

2.. In the package directory there is a Console application called RunMeToInstallAddIns.exe.

There appears to be an issue with this and the RevitAddInUtility.dll versioning. Although it works for me. It doesn’t work for others. I’m still trying to figure out what’s happening and why. I will update ASAP.

Run this to install the SDK addins to the current users directory. Note, you must have administrator rights to run this application. If you don’t , then you will have to update the assembly path of the addin in a text editor. The SDKSamples.addin is the addin for the command that adds the SDK commands as 5-6 ribbon tabs.

The line you need to edit is the assembly line in the addin. For example in the SDKSamples.addin this is :

<Assembly>Redbolts.RevitSDK.AppBuilder.dll</Assembly>

Say you unzip to the C:\SDKSamples\package directory then the above line becomes :

<Assembly>C:\SDKSamples\package\Redbolts.RevitSDK.AppBuilder.dll</Assembly>

Save the addin and exit.

To clarify this. If you have had to edit the addin’s manually you then need to copy the .addin files only to the correct directory. Depending on OS these will be:

XP:
C:\Documents and Settings\<user>\Application Data\Autodesk\Revit\Addins\2011\

Vista/Win7:
C:\Users\<user>\AppData\Roaming\Autodesk\Revit\Addins\2011\

To uninstall just delete the .addins from these directories.

3.. Start Revit and you should see the additional tabs. Note there is no checks currently in place to account for a command requiring the user to be in the family editor. So read the readme’s if you’re unsure as to what the command does.

I’ve tried to group the commands logically. But if I’ve got it wrong do let me know ;-)

Revit2011 API standout feature – being Idle

Guy Robinson — Mon, 19 Apr 2010 13:36:00 +1400

To be honest I’m loathed to single out a single standout feature from the new API’s. There is no doubt Updaters are going to be widely use. They plug a major gap in the API’s capabilities, the Updater API is well designed and are fast. However, there is a single API that does standout and in my opinion allows developers to begin the process of seamlessly integrating Revit into users BIM workflows unlike anything that has been possible before. And that API is the Application Idling event.

What happens is every time a user does nothing ;-) Revit will fire an application idling event. API developers can subscribe to this and do some work. The developer needs to make sure they don’t spend too much time in the handler and provide visual feedback on what they’re doing or the user experience will be significantly degraded and potential confusion.

There are a number of patterns possible with the Idling event and I’ll cover a simple one initially. Essentially this pattern replicates what updaters can do but in a more asynchronous manner. Although in the example command I’m not doing anything with the data. It uses an Idling event in conjunction with a DocumentChanged event to queue elements to be processed as required. The processing will only happen when Revit is idle.Here’s a screen shot:

The command opens a window that stays on top, that can be moved but not closed. The count shows the number of items in the queue to be processed and the status shows whether Revit is working or idling (orange working, green idle). I’ve intentionally slowed things down to try and show you how and when the idle event fires and the instances in the queue are processed. Create a number of elements in succession (like walls without chaining) and then double escape and watch the queue count and status update. Pretty damn cool!!

The essential class is the DataService singleton class . It’s this class I use to wire up the Idling and DocumentChanged events and generate the queue of ChangedIdTick instances to process. Here’s the event handlers for the Revit Idling and DocumentChanged events:

     /// <summary>/// Documents changed event handler./// </summary>/// <param name="sender">The sender.</param>/// <param name="e">The <see cref="Autodesk.Revit.DB.Events.DocumentChangedEventArgs"/> instance containing the event data.</param>public void DocumentChanged(object sender, DocumentChangedEventArgs e){    var activeDocument = e.GetDocument();    // this allows us to reference the document by name rather than storing documents in the queue    if (!_docTable.ContainsKey(activeDocument.Title)) _docTable.Add(activeDocument.Title, activeDocument);     // now add a tick to the queue    _queue.Enqueue(new ChangedIdTick(activeDocument.Title, e.GetAddedElementIds(), e.GetModifiedElementIds(), e.GetDeletedElementIds()));} /// <summary>/// Applications idling event handler./// </summary>/// <param name="sender">The sender.</param>/// <param name="e">The <see cref="Autodesk.Revit.UI.Events.IdlingEventArgs"/> instance containing the event data.</param>public void ApplicationIdling(object sender, IdlingEventArgs e){    if (_queue.Count != 0)    {        // if the queue has some ticks get one and sleep for 1/2 second        var tick = _queue.Dequeue();        Thread.Sleep(500);    }    //set the count rather than expose the queue to the viewmodel    Count = _queue.Count;    // now raise the event on the viewmodel    OnRevitWasIdle(EventArgs.Empty);}

And then the DataViewModel class provides the bridge between the revit dataservice and the WPF window. It subscribes to the DataServices’s RevitWasIdle event which the dataservice fires when it’s completed handling the Revit Idle event. The DataViewModel then updates the UI accordingly via databinding. If there are other aspect you’d like me to describe feel free to comment. I’ve tried to comment the code appropriately. Here’s the DataViewModel’s handler for the RevitWasIdle event.

/// <summary>/// idle handler for dataservice./// </summary>/// <param name="sender">The sender.</param>/// <param name="args">The <see cref="System.EventArgs"/> instance containing the event data.</param>private void RevitWasIdleHandler(object sender, EventArgs args){    IsIdle = true;    Count = _revitDataService.Count.ToString();    // using a dispatch timer to leave the idling radio button     // on for a 1 second    // leave IsIdle on for 1 second if it's not already running    if (!_dispatcherTimer.IsEnabled) _dispatcherTimer.Start();}

Maybe you don’t find this Idle exciting. But you might (should) when I post the next pattern…

Exciting times!!!

Code in the usual place. Note it’s a VS2010 project so if you’re on 2008 delete the .sln and open the .csproj directly, and you’ll need to update the path in the addin or use the AddInManager from the SDK to use the binary.

Revit2011 Transaction Performance

Guy Robinson — Sat, 17 Apr 2010 16:35:00 +1400

API performance has always been of interest, even more so as large projects regularly hit >300Mb now. With the new API’s such as updaters and the DocumentChanged event performance testing has got a lot more complicated. Throw in transaction and regeneration issues and it soon became obvious a different approach was required. I’m not ready to talk about this approach but I thought a little test on transactions speaks volumes about some of the additional design decisions API authors need now consider.

The test comprises 3 commands. One doing a single loop with a single transaction. The second uses a subtransaction per loop. The third one full transaction per loop. each command was run 10 times to average out variation per run. Here’s the results:

Run	Single Transaction (ms)	SubTransaction (ms)	Full Transaction (ms)
1	795	1544	73085
2	852	1553	72935
3	778	1556	72797
4	784	1554	73170
5	781	1536	73837
6	789	1564	72334
7	787	1533	71912
8	778	1541	71782
9	793	1550	73472
10	777	1524	73290
Average	791.4	1545.5	72861.4

So as you can see subtransactions were twice as slow , this is an excellent result considering 10000 were committed against only one. However as expected the majority of the overhead in the single transaction test was the committing of the single transaction, as can be seen by the Full transaction test being ~9000% slower for 10000 transactions.

So in conclusion I feel we can say:

“Utilise subtransactions as required without fear of serious performance degradation. Be very careful when considering multiple transactions within a single command cycle.”

Update: Arnošt who is part of the API team at Autodesk left a thorough comment below. So I've added his conclusion here:

“Do not use neither sub-transactions nor transactions unless you need them, but use them when the end-user benefits from having them..”

And here’s the code:

Single Transaction:

try{    var doc = commandData.Application.ActiveUIDocument.Document;    const int LOOPS = 10000;    Stopwatch sw = Stopwatch.StartNew();    var trans = new Transaction(doc, "transtest");    trans.Start();    for (int i = 0; i < LOOPS; i++)    {        doc.ProjectInformation.Name = "transtest" + i;    }    trans.Commit();    sw.Stop();    message = string.Format("Elapsed time for {0}== {1}", LOOPS, sw.ElapsedMilliseconds);    return Result.Failed;}catch (Exception ex){    message = ex.Message + ex.StackTrace;    return Result.Failed;}

Subtransaction:

try{    var doc = commandData.Application.ActiveUIDocument.Document;    const int LOOPS = 10000;    Stopwatch sw = Stopwatch.StartNew();    var trans = new Transaction(doc, "transtest");    trans.Start();    for (int i = 0; i < LOOPS; i++)    {        var subTrans = new SubTransaction(doc);        subTrans.Start();        doc.ProjectInformation.Name = "transtest" + i;        subTrans.Commit();    }    trans.Commit();    sw.Stop();    message = string.Format("Elapsed time for {0}== {1}", LOOPS, sw.ElapsedMilliseconds);    return Result.Failed;}catch (Exception ex){    message = ex.Message + ex.StackTrace;    return Result.Failed;}

Full Transaction:

try{    var doc = commandData.Application.ActiveUIDocument.Document;    const int LOOPS = 10000;    Stopwatch sw = Stopwatch.StartNew();        for (int i = 0; i < LOOPS; i++)    {        var trans = new Transaction(doc, "transtest");        trans.Start();        doc.ProjectInformation.Name = "transtest" + i;        trans.Commit();    }        sw.Stop();    message = string.Format("Elapsed time for {0}== {1}", LOOPS, sw.ElapsedMilliseconds);    return Result.Failed;}catch (Exception ex){    message = ex.Message + ex.StackTrace;    return Result.Failed;}

Cheers,

Guy

Revit 2011 Custom Ribbon Tab

Guy Robinson — Fri, 09 Apr 2010 00:14:28 +1400

At the beginning of the year I showed you how to add your own tab to the Revit Ribbon. I’ve updated this now for Revit 2011. However, I’ve taken the chainsaw to my code for 2 reasons. The API wasn’t very elegant and the 2011 ribbon seems to behave itself a lot more than the ribbon in Revit 2010. So there is no need to manage context switching as in Revit 2010. Having said this, if anyone finds this new code isn’t behaving please let me know ;-)

The code is now implemented as an extension method to the UIControlledApplication . This means as long as you reference the extension method namespace correctly you should see this in intellisense when creating a custom tab:

And when creating a panel there are 2 additional overloads:

Although the extension method is contained in the example assembly I’ve designed the extension method to sit in an external common assembly that all your commands use. As long as all your applications use this common assembly you will be able to add panels to a common ribbon tab by name.

So in summary to add a custom tab use the following :

public Result OnStartup(UIControlledApplication application)
{
    try
    {
        var tab = application.CreateRibbonTab("MyTab");

And to add a panel to the custom tab there are 2 overloads. The first where you pass the tab instance:

var tab = application.CreateRibbonTab("MyTab");
var panel = application.CreateRibbonPanel(tab, "Test Panel");

And the second where you name the tab

var panel = application.CreateRibbonPanel("MyTab", "Test Panel");

rather than creating it explicitly. If the tab with the specified name doesn’t exist the extension method will create it. Code in the usual place along with a binary and addin. Note you’ll need to modify the path in the addin .Enjoy!!

Journal Comments

The example application contains a few other examples of nice new API’s for Revit 2011. The minor one is the ability to easily add a comment to the journal. This is a method to the Revit Application instance so you can add comments from either external applications or external commands:

Application.WriteJournalComment("It's verified you do agree",true);

If you don’t want to write the time your comment was added to the journal use false instead.

Task Dialog Boxes

The other new API in this example application are Task Dialog boxes. These dialogs will be useful in many situations where you want to alert users to an event , a simple window for getting user feedback, help windows etc. The example pretty much covers all options. A nice feature is the addition of up to 4 linked command buttons providing an easy way to get more than the usual yes/no response to a dialog. In the example application I’ve added 2 commands:

td.AddCommandLink(TaskDialogCommandLinkId.CommandLink1,"A jump …");
td.AddCommandLink(TaskDialogCommandLinkId.CommandLink2, "A jump …");

Then a switch to action the user response. Clicking on a link closes the dialog:

switch (result)
     {
          case TaskDialogResult.Close:
               app.WriteJournalComment("closed dialog", false); // writes a 
               break;
          case TaskDialogResult.CommandLink1:
               Process.Start("http://www.lukehurley.co.nz/biomusic/ 
               break;
          case TaskDialogResult.CommandLink2:
               Process.Start("http://www.lukehurley.co.nz/2008/07/06/

               break;
     }

The other new API I use in the example is the interface IExternalCommandAvailiability to disable the command in the family editor (just wanted to check tab behaviour in the family context). Jeremy covers this API in depth so I won’t bother ;-)

Revit 2011 on Windows Phone 7 Series

Guy Robinson — Thu, 01 Apr 2010 15:05:03 +1400

For those who thought the ribbon and Revit were a joke. Well I’ve got news for you. Thanks to the power of the Visual Studio 2010 Phone 7 series development tools and the Revit Ribbon, I’ve been able to get Revit 2011 running on the emulator with the minimum of effort. Although it is a little slow in the emulator.

Here’s a screenshot of the port of Revit 2011 Architecture running on the Phone 7 emulator. Fantastic stuff. Looking forward to a decent iPad sized device from Windows in the coming months.

Revit2011 API – What’s in a name?

Guy Robinson — Sat, 27 Mar 2010 12:14:03 +1400

As Jeremy noted Revit 2011 API has had a major refactoring of the namespaces as well as splitting into 2 assemblies. Before I start talking about the lovely new functionality in this release I want to discuss the implications of this change. In many ways this is the most significant aspect of the Revit2011 API.

Why have they done this? It’s a huge job and you wouldn’t do it by choice. Related to this is the move away from a relatively unique API in VSTA which used proxies and AppDomains to implement the compile/run/recompile cycle VSTA allows. VSTA now has exactly the same API as the standard API, and some magic for the reload cycle in VSTA. This will make the use of common code libraries in VSTA straightforward and no doubt lower the workload for the API team.

The basis for the namespace changes is a move by the Factory to using semi-automatic code generation tools to generate the .NET API. Simplistically what this means is the .NET API is as close as we get to a view of the source code. The .NET API’s essentially mirror those used internally for the base Revit application. A classic example of this is the renaming of the Symbol class to ElementType. In .NET {some name}Type naming is usually reserved for enum’s. Yet ElementType is a class in the new API as this is what it’s named in the unmanaged world. For experienced .NET developers and those new to the Revit API a casual parse of the API may be a bit confusing in places but on the whole the new structure of the API and the namespaces is logical.

The move to code generation tools is very significant for a number of reasons (in no particular order):

It’s both enlightening and instructive to see how they have designed API’s internally.
It means the API team should have more time to implement new features rather than fighting the transition between the unmanaged and managed worlds. Testing should be easier. No excuses for missing functionality in the API now ;-) ;-) (Not true as explained below)
We automatically get a significantly more powerful API. Namely in direct support for Revit transactions ,failures and exception handling API’s. This does mean we can’t avoid implementing transactions at the very least. For beginners it’s yet another thing to understand but luckily the API is both powerful and easy to understand.
Implementation of new base functionality via the API, is relatively straightforward. 2 good examples of this are the new sheetholder API and reporting parameters. Reporting parameters will be widely used and having API support from day one is fantastic. Robert has a good introduction to them here.
More generics and better support for .NET language features in VSTA and the base API.

Given these code generation tools are semi-automatic, for the average punter and API developers I believe it gives us pointers to some of the internal struggles the Factory may be having with the Revit codebase. We’ve all had long standing requests for improvements in stairs, addition of groups, worksets schedules etc in the API as examples. So as we move into future releases of the API, excluding lack of resources if a feature isn’t added in the API we can hazard a guess as to why:

The internal API could be a bit of a mess and doesn’t map well to the .NET world. In this case it’s reasonable to assume the internal API’s are on the todo list for a rework.
There is major changes in the base application planned and exposing the current API is undesirable.

Undoubtedly this release has been a massive amount of work for the API team and I’m sure they’re well overdue for a holiday. Moving on to future releases though should make their job easier and each new release even more impressive for 3rd party developers. Exciting times!!!

Just to finish, for those with a reasonable sized legacy codebase and developers in general, the namespace changes are a walk in the park for Resharper. So if you’re serious about developing I can strongly recommend Resharper . At the moment if you buy V4.5 you get an upgrade to V5 for free. It’s an essential tool for me and has made moving to Revit2011 a walk in the park.

Yeah Baby!! Revit 2011 API – the unofficial 4th Discipline

Guy Robinson — Thu, 25 Mar 2010 22:54:44 +1400

So apparently we can talk about Revit 2011 now and wow, can we talk about Revit 2011 and the API…

YEEEEE HHHAAAAAA!!!!!!!!!

True be told, my initial reaction on reading the API what’s new.pdf was more like this (from 1 min 33sec) but apparently that’s NSFW ;-)

Last year I talked about how this release would be the most important ever. I’ll cover that post in detail later, along with the new functionality . For now I just want to congratulate the Factory and in particular the API team for a massive, exciting and compelling release. And those words don’t do it justice.

The scale of the improvements suggests a cautious rollout but for most firms of any scale this will be a must have release. For those serious about the API the biggest headache is which lolly do you eat first, the bag is so big.

If you’re serious about the ‘I’ in BIM, the Revit 2011 API will elevate the API to the unofficial 4th discipline in your Revit toolbag.

Congratulations Autodesk, the Factory and especially the API team!!