I’m on my way to San Francisco for some internal meetings (including a Hackathon, over the weekend, which should be fun), but have unfortunately been held up at Heathrow by fog (it delayed my inbound flight, along with many others’, but somehow didn’t stop my outbound flight from leaving, which always seems to be the case… I then had to queue for 2.5 hours to get a new flight, the only highlight of which was standing behind members of the junior Kuwaiti ice hockey team [at least that’s what they said they were – they may have been pulling my leg {it was that kind of day :-}]). And so, having spent the night at the Holiday Inn on junction 4 of the M4, I’m now at the airport waiting to catch my Virgin Atlantic flight (a change from BA) to SFO.
I’ve decided to skip talking about the other new APIs in AutoCAD 2013, for now – I’ll look at that more closely next week – but did want to get back to the issue of migrating .NET applications to work with AutoCAD 2013.
Yes, there is a break in binary compatibility for .NET applications in this coming release. ObjectARX developers have been used to see application compatibility (only) broken every 3 releases since AutoCAD R14, but this is the first time that .NET applications will have needed to be rebuilt since AutoCAD 2007 – at least for developers relying on the core API capabilities made available in that release. Which means there are many applications out there with .NET modules that work for AutoCAD 2007-2012.
Mainly due to The Big Split mentioned in this previous post, we now have an additional DLL dependency in .NET projects for AutoCAD 2013: you need to include a project reference to AcCoreMgd.dll (in addition to AcMgd.dll and AcDbMgd.dll). If you use the opportunity to write “core” apps (which can, for instance, be loaded in the Core Console) then you will end up replacing your reference to AcMgd.dll with one for AcCoreMgd.dll.
That’s the big change, and the reason why it will be impossible to load older applications in AutoCAD 2013 – the binary code implementing API functionality has physically moved – but for good reasons.
Along with API implementations moving from acad.exe to AcCore.dll (and their public declarations moving from AcMgd.dll to AcCoreMgd.dll), we’ve also added some namespaces to house extension methods for API capabilities that need to be used in full (rather than core) applications: DocumentExtension, DocumentCollectionExtension, EditorExtension, WindowExtension. You will find that certain methods can’t be found when you reference the AutoCAD 2013 DLLs – in most cases it’s a simple matter of adding the right namespace to your project, but in a few cases you’ll find properties/methods have been renamed – mostly to make them more descriptive.
For instance, the existing property to get AutoCAD’s status bar is:
Autodesk.AutoCAD.ApplicationServices.Document.StatusBar
In AutoCAD 2013, this has been changed to:
Autodesk.AutoCAD.ApplicationServices.DocumentExtension.GetStatusBar()
So a little different, but hopefully not to find to track down and manage. The ObjectARX SDK contains migration information that will help identify and make these changes.
An important point to note is that you’ll also need to target .NET 4 for your applications to work with AutoCAD 2013.
Those are the main migrations steps, then:
- Change your project’s settings to target .NET 4 (if it doesn’t already)
- Add an assembly reference to AcCoreMgd.dll
- Fix your code to compile properly, which may mean:
- Changing property and method names, as per the migration guide
- Adding namespace references (Imports or using statements) to a few new namespaces
Stephen Preston tells me it took him about 10 minutes to migrate the MgdDbg sample project – which exercises a huge amount of the AutoCAD API, so is a pretty good reference for a real-world application.
A few additional points to note…
If you’re using COM Interop, you’ll find the interop assemblies are no longer registered in the GAC (i.e. you won’t find them on the COM tab in the Add Project References dialog). You’ll now need to browse to Autodesk.AutoCAD.Interop.dll and Autodesk.AutoCAD.Interop.Common.dll (I believe) in the AutoCAD Program Files folder or on the ObjectARX SDK. Hopefully Visual Studio will know to embed types from these assemblies, which will make deployment more straightforward.
Speaking of deployment… yes, you will need to have (at least one) different module(s) to support AutoCAD 2013 along with AutoCAD 2007-2012 (the number will depend on your application and how it is structured), but using the Autoloader will definitely simplify your deployment of these modules for different releases.
It should also be possible to have the same source files build to different modules (you may need to add some conditional compilation settings – something I should address in a blog post, at some point).
My flight’s gate is about to open, so I’d better sign off. I don’t want to miss this one!
Update:
Stephen Preston just pointed me to a thread on The Swamp where the question of the terminology used to describe the containers housing these extension methods (namespaces vs. static classes) has come up. Stephen has addressed the question in a post on the AutoCAD DevBlog, where he explains the reason for the confusion. It seems I'd unwittingly propagated this confusion in this blog post, so be sure to check Stephen's post if you're in any doubt on this issue.
