I’m very pleased to announce the availability of this really interesting Plugin of the Month over on Autodesk Labs: Batch Publish for AutoCAD. Here’s an excerpt from the ReadMe (which I happen to have written, but anyway):
This plugin can be used with AutoCAD to simplify the process of publishing sets of drawings to DWF and/or PDF. It runs as a command within AutoCAD – as opposed to a separate executable – and uses a separate executable to monitor AutoCAD's health and restart it, as needed. The status of the batch publishing operation is stored to disk, allowing it to pick up from where it left off and also for any failed documents to be retried without starting from scratch. A setting is available to only publish drawings that have been modified since they were last published, making it easier to publish sets of documents on a regular basis.
Varadan Krishnan and Viru Aithal from our DevTech India team have been working hard on this tool for some time. Viru and Varadan have added some very interesting enhancements over the last few months, as the plugin has evolved, and I think it’s going to prove a very useful tool for anyone needing to publish sets of drawings to DWF or PDF.
Typical batch publishing applications often take the form of standalone applications which call through to AutoCAD using COM to drive the publishing of drawings. This application takes a slightly different approach: it runs in-process to AutoCAD, as a standard .NET plugin defining a BATCHPUBLISH command, and this command will load and publish the various documents you care about, one after the other. So you have access to your publishing task right there in the AutoCAD application: no need to launch anything external. That said, as you’re launching a batch processing operation – which may be trying to read problematic source drawings – it’s highly recommended that you save and close any drawings you’re working on. As we’ll see below, AutoCAD may get restarted forcefully during the operation, so it’s highly recommended to launch it from a fresh instance of AutoCAD (or at least one with no unsaved drawings open in the editor).
The application uses a couple of very interesting techniques which may be of interest to people looking at this from a development perspective. Firstly, it has a separate little “regulator” application which monitors the health of AutoCAD: if AutoCAD hangs on loading a corrupt drawing, or the publish operation is taking suspiciously long to complete (relative to a user-defined timeout value), the regulator kills the AutoCAD session and restarts it, making sure the batch publish operation starts back up just after the problematic drawing. Once the other drawings have completed, the user can then choose to retry publishing of any unpublished drawings, specifying a different timeout, as appropriate.
The other technique that I found interesting is the way the application calls through to AutoCAD via COM: it uses Document.SendCommand() to drive AutoCAD’s PUBLISH command synchronously, but – rather than creating a dependency on AutoCAD’s type library, which adds some complexity in terms of multiple version support – the code uses Type.InvokeMember() to dynamically call SendCommand() without needing the type library. The same effect can be achieved in VB quite easily using late binding and now in C# 4.0 we have the dynamic keyword or can embed specific types from a type library rather than needing the whole thing – but for older versions of C# this is a viable and interesting technique if you’re only interested in a small portion of an application’s COM object model.
The application makes heavy use of an XML file to persist information about the status of the batch publishing operation. This has a number of benefits, especially related to resuming the operation in case AutoCAD needs restarting, as well as restoring some temporarily-overridden system variables when everything’s finished. The approach used to read and write the XML is probably slightly lower-level than might have been used – especially as .NET provides some very interesting object-level XML serialization capabilities – but the need to persist a variety of different pieces of data at various times during the batch publishing operation led to this approach being adopted, for better or worse. The current implement works well, but this is potentially one section of code that might be streamlined in a future release.
Now let’s take a look at the BATCHPUBLISH command in action…
The first thing to do is to copy both the program files provided - ADNPlugin-BatchPublish.dll and its companion ADNPlugin-BatchPublishRegulator.exe – into the same folder on your local hard-drive (preferably AutoCAD’s main Program Files folder).
Then we can NETLOAD the DLL into AutoCAD – which will create demand-loading entries for subsequent loads – and launch the BATCHPUBLISH command:
Once we’ve filled out the information in this main dialog…
… hitting configure will allow us to do additional fine-tuning of the application settings. We can choose whether to look for both DWG and DXF files in the source directory and we as having the option to exclude specific files or layouts. We can also change the timeout after which AutoCAD will be killed and restarted, as well as being able to choose whether to publish only the drawings that have been modified since the last time they were published (the alternative being to force a re-publish of everything).
Once we’ve finished, we can select “Done” and then launch the batch publish via the “Publish” button on the main form. You’ll now see AutoCAD publishing the various drawings from the specified source folder, along with a small dialog displayed by the regulator application. This will count down from our timeout threshold and will restart AutoCAD when it gets to zero.
30 seconds isn’t a very long time to publish both a DWF and PDF for complex drawings. If it’s clear that the timeout isn’t giving enough time for AutoCAD to complete both and the publish seems to be happening correctly, then you can either close the regulator (which will lead the rest of the batch publish to not be monitored, but will otherwise have no ill effects on the operation) or you can let AutoCAD be restarted and then try again later with a larger timeout value. In our case we’re going to do that.
Once AutoCAD has been killed we’ll see this message from the regulator:
The application waits for 10 seconds after killing AutoCAD before restarting it…
… and the batch publish operation should continue until all drawings have either been published or have failed to do so:
From here we can use “Retry” to attempt to publish any failed drawings again (possibly with a longer timeout specified in the top right of the dialog):
We should now find our output folders filled with DWFs…
… and with PDFs:
You’ll see two log files in each folder, as it took us two batch publish attempts to get the whole set of drawings published.
Please give this tool a try and let us know if you have any feedback. Batch processing tools are often quite hard to get right, so please don’t be discouraged if it doesn’t work perfectly on some of your drawings: please let us know and we’ll do what we can to fix the issue.
