When Vault 2012 came out, it introduced the events feature, which allowed you to write your code once and have it hook to all Vault clients on the machine. However, I want to point out that these events are version specific.
This aspect wasn’t a problem in Vault 2012, because you needed the 2012 API to connect to the 2012 server. But now, the web service compatibility feature in Vault 2013 adds some complications. The Vault 2013 server supports a mix of 2012 and 2013 clients. For example, an engineer can use Vault Explorer 2013 and Inventor 2012 on the same vault. If you write an event handler, it’s not going to be able to hook to both sets of clients.
When you write an event handler, you are writing an extension, and extensions are bound to a specific version of Vault SDK DLLs. For example, if you use the Vault 2013 API to hook to the post check-out event, you would only get events from 2013 clients. Any 2012 clients would completely bypass your event.
How to workaround:
- You need both the Vault 2012 SDK and Vault 2013 SDK.
- Create an assembly project, reference the Vault 2012 SDK DLLs, and write your event handler.
- Copy the assembly project, change the references to Vault 2013 SDK DLLs, and rebuild.
- When you deploy, you need to deploy both assemblies to the appropriate locations.
Steps 2 and 3 can be done in any order. But the idea is you have two separate assemblies to build.
There are some things you can do to minimize the code copy. One technique is the “paste as link” feature so that you can share source code projects. You can also break out logic into a separate utility DLL, as long as it doesn’t reference any Vault DLLs.
Things that will not work:
You are welcome to try other approaches to solving the problem, but I’m here to tell you that the following approaches will not work.
- Create a Vault 2013 or 2012 extension and deploy it to both the 2012 and 2013 extension folders.
Vault will only load extension with the matching ApiVersion attribute.
- Create an extension that references both 2012 and 2013.
Visual Studio will block you.
- Dynamically load the correct SDK DLLs at runtime.
Remember that you are an event handler. You don’t call the Vault API; the Vault API calls you. The DLLs are already loaded.
I’ve said this before, but event handlers that hook to all Vault clients is not a good idea in practice. For a number of reasons, I’ve found that it’s much better if you can hook to a specific app. This compatibility issue is just one more reason.
Here is an article on event scope, if you want to know other ways to hook to web service events.