Wednesday, September 13, 2006

.NET vs. COM in AutoCAD - What should I use?

Kean Walmsley writes about the pros and cons of .NET vs. COM in AutoCAD on the "Through the Interface" blog.

In general, a good article - but I don't think it addresses two of the biggest "gotchas" of AutoCAD.NET...

The Blessing/Curse of Versions
One of the goals of .NET was to avoid some of the issues of "DLL Hell", where different programs linked with different versions of DLLs without worrying about whether the differences were significant.

Now when I make an AutoCAD.NET application, it gets linked against the file "acmgd.dll" version (in vanilla AutoCAD 2007). If is not available later, you're out of luck...

Problem #1: Versions within AutoCAD and vertical Releases
In the AutoCAD 2005 release, we ran into a problem where vanilla AutoCAD was version, but the version of Autodesk Map3D 2005 and in various service packs was version

Now - Autodesk has been far better about being nice about not changing the version randomly in 2006 and 2007... But there may come a time when it's necessary in mid-release, and that makes a lot of stuff break!

Problem #2: Versions between AutoCAD Releases
This one there's really no getting around... Each release of AutoCAD will have a different version of acmgd.dll... And as a result, your application will need to be recompiled for each version.

This is a disadvantage compared to both ARX and COM... In ARX, Autodesk has been fairly succesful at making ARX applications binary compatible within 3 release blocks (2004, 2005, 2006, for example)... With COM, I suspect because the COM layer "insulates" the application from changes even further, there are people who can still run the VB application they wrote for AutoCAD 2000 in AutoCAD 2007 (OK, so there might be some changes - but it's the exception rather than the rule)...

Don't get me wrong - I'm still a HUGE fan of .NET for application development... But the benefits that it brings are not without their costs compared to ARX and COM. I've also noticed that there may be some relief from this in Visual Studio 2005 (although I don't quite have my head wrapped around the "Specific Version=FALSE" option).

Editor's Update: Kean has put in a comment that clarifies this issue:
The short, tongue-in-cheek version: In 2005, 2006 and 2007 it was intentionally broken, but going forward it will be the same as ARX ... So 2007,2008, and 2009 would presumably be binary compatible. Thanks Kean!

Friday, September 08, 2006

What's new in the Revit 9.1 API?

I don't know if you're like me... but as a CAD application developer, each new release is like your birthday... You have a stack of gifts in the form of new API calls that you have access to... And it's much more intense in products that are in early stages such as Revit (as opposed to how I felt about Pro/Engineer's 24th release).

So I immediately sat down when I got my hands on the Revit 9.1 Beta and tried to understand what was new - and what each new piece of capability might mean to me (and my customers)... What new powers would we have?

Well, in all the hubbub I didn't notice that Revit 9.1 was officially released last week - so here's my notes that I've been sitting on...

To extend the birthday metaphor, some presents turn out to be rockets, other presents turn out to be socks - and still other presents, like those from "Uncle Bill", just leave you scratching your head...

Related Posts:

What's new in Revit 9.1???

First of all, there are a variety of new elements that can now be programmatically created:
  • AreaBoundaryConditions
  • BeamSystem
  • LineBoundaryConditions
  • MaterialSet
  • ModelCurve
  • ModelCurveArray
  • PathReinforcement
  • PointBoundaryConditions
  • ReferencePlane
  • Room
  • RoomTag
  • SketchPlane

As you can tell, this is a mixed bag - many of these are specific to analysis applications - but there are certainly some other neat ones, including Rooms and Room Tags, ModelCurves (which can include lines, arcs, splines, etc).

Materials have undergone a significant overhaul, and are much more useful. There is much better definition and control of material types (including specific handling for Wood, Steel and Concrete) - but also better handling in general for things like rendering, smoothness, shininess, fill/cut patterns, etc... Some of these things used to be available via the built in parameters on the Material Element - but many have now been promoted to actual class members, and they work much better that way...

Rooms/Room Tags
One of the nice pieces for FM or space planning related applications is being able to create Rooms, and be able to read and create Room Tags. As a side note, Room Tags can tell which Room they are associated with (however, Rooms don't know their tags).

Detection of Current Display Units
At last!!! How could we ever live without this?!?! Particularly for those of us who work in both metric and imperial worlds, and those of us who dream of someday writing a packaged application for Revit!

Suspension of Disbelief
OK, so actually it's called "SuspendUpdate" mechanism - and it allows you to temporarily suspend Revit's updates and consistency checking while you're making geometry changes. (I haven't needed it yet, but I'm sure it's there for a reason that I just haven't tripped over yet).

New Element Classes
The following elements have been promoted from type-less Elements (where you could just kind of guess what it was) to actual identifiable object status.

  • Opening
  • LayoutRules
  • FillPattern

Generally these are things which you can now read (or update) some specifics about them - but you can't create them from scratch.

In terms of compatibility with Revit 9, it appears to be pretty good. The only thing I've noticed so far is that they renamed the "MaterialElement" class to just "Material" - once I fixed that everything appears to work identically.

In Summary
All in all, I have to say I got a few more socks than rockets (but that's me - who hasn't been called on to do much in the analysis integration - your excitement may vary)... But it's a solid release, and you can tell that they're committed to significant expansion of the API.

And if the various insiders that are contributing to the Revit API newsgroup are correct (here and here and here), then we have a lot to look forward to in the Revit 10 API. Maybe that will be the release that puts the API over-the-top (for me :) ).

Thursday, September 07, 2006

Dealing with .NET 2.0

OK, so this is a little bit off my mainstream topics of CAD-specific application development... But I'm hoping that it's useful either to the CAD people or .NET developers in general...

As you may know, in the CAD world, we're (finally) being driven to .NET 2.0 (at least in the Autodesk world - I get the sense that the PTC/Dassault/UGS worlds, which are still multi-platform, are not pushing it as aggressively)...
For example:

  • AutoCAD 2007 - DotNet 2.0 mandatory
  • Revit 9.0 and 9.1 - DotNet 2.0 mandatory

But I ran into a problem with two of our clients in the same week, with the same issue in different applications. In both cases, they were deploying our applications onto new machines. And when they tried to run the applications, in both cases they got:

System.TypeLoadException: Could not load type`system.runtime.compilerservice.runtimecompatibilityattribute`from assembly`mscorlib, Version=, Culture=neutral, publickeytoken=b77a5c561934e089`"

(or something close to that)...

What was the issue? In both cases, the machines had .NET 2.0, but they had the BETA version of DotNet 2.0 installed (build 2.0.50215). But the behavior was strange - some of the code executed, but other parts didn't... In any case, the TypeLoadException should be a red flag for developers.

How is it that these people had beta versions of .NET running around? Who knows... Obviously some early-adopter-developer sent them something that required it, and now we have to deal with the aftermath!

This is a complicated issue - I'm pretty sure that AutoCAD 2007 installs 2.0 as a pre-requisite. However, the Revit products do not (and our other product was a self-contained Vault application)...

So - to paraphrase Esterhaus on the police drama Hill Street Blues, "Let's be careful out there".

(Check during install for the existence of C:\Windows\Microsoft.NET\Framework\v2.0.50215, perhaps?).