SpaceClaim’s Versioned API

Today we released new installers of our SpaceClaim add-ins which support SpaceClaim 2010. SpaceClaim released 2010 just a couple of days ago and in fact our add-ins were ready the same day. Just that we needed to make some very minor changes and test them thoroughly with the new version.

Usually partners get access to the beta versions so that we can test our add-ins with it. I am not sure exactly why, but SpaceClaim didn’t do that this time. At least not with me. But it didn’t make much of a difference. That’s because they use a versioned API, which is something that probably needs a little explanation. Here is what the SpaceClaim installation folder looks like.

The highlighted folders contain one DLL each and some documentation on how to use them. The DLL file name is the same as the name of the folder and is basically a snapshot of the API that is frozen for life. This means that no changes will be made to the DLL in a future version of SpaceClaim. All SpaceClaim add-ins need to talk to one of these API DLL’s. Which one is entirely up to the add-in developer. For example, all our add-ins talk to the SpaceClaim.API.V4.dll. Even the updated ones that we released today. Why? Because they do not use any new features added to the later versions of the API DLL’s. So there is really no benefit in linking our add-ins to V7 of the API. If we did then people using earlier versions of SpaceClaim would not be able to load our add-ins since their version would not have V7 of the API.

There are a number of advantages to having a versioned API. For starters, the add-ins will work with all future versions of SpaceClaim. At least technically they should. But its a good idea to test anyways. Secondly, as a developer you can be sure that your add-ins will work in the same way in a future version of SpaceClaim. For instance, suppose the API was not versioned and there was just one API DLL which got updated with every new version or service pack of SpaceClaim, the add-in would behave differently if it called a function in the DLL whose functionality had changed. Lets suppose I used a function in the API that wrote out a R12 DXF file which was to be used as an input to some other external operation. Now suppose five years hence, for some reason, SpaceClaim drops support for R12 DXF and instead writes DXF files from AutoCAD 2000 onwards only. My add-in may continue to load into SpaceClaim but will not be able to do the job because it relied on an API function that can no longer write a R12 DXF file. There are ways of preventing this by creating different versions of the functions in the same DLL. But that is really under the control of the CAD vendor and not the add-in developer. For this reason it is quite common to read warning messages like the following in the API documentation: “This function is deprecated and may not be available in a future version. It is strongly advised to use this other function instead.

Developing SpaceClaim add-ins is quite simple and straightforward. You can join their partner program. But I don’t think that’s a requirement since the API is open and included with the product itself. SYCODE is a SpaceClaim Technology Partner and I have personally worked with SpaceClaim since V1 of the API. Actually I find it kind of funny. Years ago, when the company started out, I was working very closely with their technical team developing our add-ins while at the same time bitching about their business model on this blog. But then I do that with just about all the CAD vendors. I get the feeling that their technical and marketing teams don’t discuss work with each other a lot. 😉

  • To be clear, once released, we strive to keep an old version consistent. There are some exceptions:
    * We release beta versions of the upcoming version of the API, which are subject to change until finalized. SpaceClaim 2007 includes API v7 beta 1. It may changed until out of beta.
    * We fix bugs in old versions of the API as long as that fix doesn't change behavior.

    I should add that sometimes we make significant changes from version-to-version of the API. As with our interactive UI, we spend a lot of time behind the scenes, cleaning things up and making them better. It's like a messy room: sometimes you have to throw some stuff out to get it clean. We'll do that with the API so that any new user don't have to deal with years of mess. Sometimes we'll rename things to make it more consistent. It can take a little more time to move your add-in to a new version, but you get productivity back by having a more efficient and tidy API.

    -Blake (a founder of SpaceClaim and an avid SpaceClaim API user)

  • There is one more advantage of making versions of API. The add-in developer can “Add Reference” to different version of the DLL and create separate addins for each version, say AddinX for SC2008, AddinX for SC2009 so on, and he may not have to install all those versions of SpaceClaim. In fact, SpaceClaim2010 just overwrote my earlier installation of SpaceClaim2009.

    If I remember correctly, for Inventor addins, the reference can only be added for its versions which are installed on the developers computer.

    Please correct me if I am wrong.

    -Rajeev Lochan

  • Rajeev,

    Even if SpaceClaim 2010 overwrote 2009 the API DLLs will still be there. For example, we link to V4 and V4 still ships with 2010. Or maybe I didn't understand your issue correctly.

  • Deelip,
    I actually meant the same as you explained. Though SpaceClaim 2010 overwrote 2009, we can still develop addin for 2009 version.

    In summary:
    As an Addin developer, I need not install all versions of SpaceClaim to develop addins for those versions. Only the latest version is sufficient. Whereas in other CAD systems, we may have to install all those versions to develop addins for them.

  • Sorry, I misunderstood. However, to avoid the problem you mentioned, I make it a point to copy the API files to a different folder on my hard disk and use those instead. That way, even if I am on the road on my netbook and a particular CAD system is not installed on it, I can still change the code, build the plug-in and send it to my office to test and release.

  • Apple

    What language to you code your spaceclaim addins in?

  • I use a mixture of C++ and C#

  • I write all my personal stuff on C#. Our architect is starting to write F# add-ins, but perhaps that's a little crazy. Anyone else playing with F#?

    • George Ham

      Hello,can you tell me how to develop the Addin of spaceclaim on vs2013

  • F#? Yeah, that IS a little crazy. 😉

  • I prefer D minor.. it's the saddest of all programming languages