The Vault 2012 API has a formalized concept of an Extension. In the Vault 2011, the concept was there, but there was no clear set of rules or behaviors. By defining things more clearly in 2012, the concept is easier to understand, and the groundwork is laid for future API enhancements.
A Vault Extension is a component that doesn't run on its own, but gets loaded by the Vault framework.
Currently, there are 3 types: Vault Explorer extensions, Job Processor extensions, and Web Service Command extensions.
There is a common set of rules that all extensions must follow.
- They are all .NET assemblies.
- They must have values for 5 specific assembly attributes: AssemblyCompany, AssemblyProduct, AssemblyDescription, ExtensionId, and APIVersion.
The first three are put in by Visual Studio. The last two are from the Vault API.
- They must be deployed with a .vcet.config file.
- They must be deployed to a folder under %programData%\Autodesk\Vault 2012\Extensions. 1 Extension per folder.
- They must have a single, public class that implements the interface for that extension type.
The interface implementations are important because the Vault framework uses that class as the entry point into your customization. The interface is how the Vault sees your code, and Vault is not concerned with anything underneath.
Vault Explorer Extensions:
|Description:||Vault Explorer extensions are for extending the Vault Explorer client application. Commonly used for things like adding commands and tab views.|
|ExtensionType in the .vcet.config:||VaultClient|
Job Processor Extensions:
|Description:||Job Processor extensions are for extending the Job Processor application. Commonly used for creating job handlers for custom job types.|
|ExtensionType in the .vcet.config:||JobProcessor|
Web Service Command Extensions:
|Description:||Web Service Command extensions are for responding to events from any Vault client running on a computer.|
|ExtensionType in the .vcet.config:||WebService|
|Loads in:||Any application using Autodesk.Connectivity.WebServices.dll on that computer.|
Mixing and matching:
It's possible to have a DLL to implement more than 1 extension type. In fact, this works really well with the Job Processor and Vault Client extension types. Mixing the Web Service extension type with other types is trickier because you don't know the application context. As a result, the DLLs from the other extension type might not be available to the running application.
Job Processor and Vault Client work well together because they have the same working folder, and therefore, have access to the same DLLs.