Autodesk Vault API 2017: 32-bit/64-bit challenges....

For end-users of Autodesk Vault - it's probably a welcome development that Autodesk Vault 2017 now supports a 64-bit version (and a 32-bit version if you're still running on a 32-bit OS).

Less so - however, for Vault developers, whose lives may get more complicated. The explanations in documentation and social media have been somewhat lacking (Where are you Doug Redmond? The citizens of Vault API land need you!).

Here's what I've managed to piece together so far:

The SDK
You'll see that the SDK ships with two subfolders of the "bin" folder - "x86" and "x64". The bulk of the DLLs inside of both folders are technically "ANYCPU (64-bit preferred)" - with the exception of the new Clic License Manager loader DLL, which seems to be platform-specific. (The Clic thing is something else that could use a bit more explaining than we've been given).

The Vault Explorer Environment
If you're doing Extensions within Vault Explorer, it's pretty straightforward: If you install on a 64-bit machine, you get the 64-bit versions. The documentation says that you'll have to make sure your DLLs match the bit-ness of Vault Explorer... But I believe that it IS possible to use ANYCPU for your explorer customization DLLs (they should match the Vault Explorer automatically, and all of the referenced DLLs are ANYCPU).  So that's not really bad at all (unless you've got 32-bit-specific dependencies in your project - and then you're in for a longer day, even after you've got things worked out... Separate DLLs, separate installers, etc).

Vault Job Processor
Seems to be the same as the Explorer issues above.

Standalone Vault Applications
This is the one that really had me puzzled for a little while. I was naively thinking that I could leave my standalone Vault apps as 32-bit (even on a 64-bit machine). That might work in some cases, but if you've used any of the higher level pieces of the framework (VDF, etc) - then you're out of luck. Those pieces of the framework will attempt to load any Vault Extensions that you have loaded on the current machine - and seem to cause problems if ANY of the Vault Extensions don't match the bit-ness of your standalone app.

So - if you're doing standalone apps for sale, or other cases where you can't guarantee the bit-ness of the operating system, then you may need to do two versions of the apps... One 32-bit and one 64-bit.


All in all, this stuff just kind of snuck up on me - I don't recall hearing about it back at Developer Days - so it's been a more complicated upgrade process than I anticipated.

Good luck out there...

Vault 2008 and WSE 3.0

I wrote this post some time ago - when I wasn't sure where the embargo on Vault stood... Now I think I'm in the clear, since at least Productstream has been officially released.

Warning: This is a pretty obscure post - so if you're not involved in Vault development, you might want to pass on this one!

The next version of Vault (2008) is catching up to the latest in Web Standards from Microsoft - Web Services Enhancements 3.0. This will be nice, because WSE 3.0 is the only version that plays nicely with Visual Studio 2005 (leaving developers to jump through some hoops to make things work).

Along the way, I found out about a few issues that make Vault development a little more challenging...

1. Ticket changes
The behavior of the SecurityHeader ticket has been improved... Prior to now it tended to be the same for a long time (I'm not sure if I have it figured out, but you could restart the webserver, and your ticket would still be valid). Now, if you try restarting the webserver, your client's ticket is no longer valid, and you get a SoapException #300.

Working around this scenario means implementing either partial classes or derived classes to be able to store the userID and password, then do a "try/catch" around the actual invoking of the Web Services method... If you get a 300, then you need to try to re-login and then re-Invoke...

2. Download file changes
The signature for the file download has changed - instead of using DIME attachments, the routine just passes back a byte array... However, it's important to note that there is a client config setting called "MTOM" which should be turned on in order to have efficient transfers (if you don't, files will transfer in base-64 ascii mode rather than as binary - making them perhaps 30% less efficient).





3. Time is of the essence
Maybe it was the DST debacle - or maybe either WSE 3.0 or Vault 2008 is more sensitive about time differences between client and server. I know that while doing some wide-area testing, my machine clock was out-of-sync with the Vault 2008 server by about 10-15 minutes - and it would not let me work (buried down deep in the exception was a very clear message about the time tolerance setting). In particular I think it doesn't like it if the SecurityHeader looks like it was generated in the future.


Well - I hope that this was useful to Vault developers out there...