What Makes a "Vault Extension"

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.

The Definition:
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.

The Rules:
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 interfaces:

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.
Interface: Autodesk.Connectivity.Explorer.Extensibility.IExtension
ExtensionType in the .vcet.config: VaultClient
Loads in: Connectivity.VaultWkg.exe
Connectivity.VaultCollaboration.exe
Connectivity.VaultPro.exe

Job Processor Extensions:

Description: Job Processor extensions are for extending the Job Processor application.  Commonly used for creating job handlers for custom job types.
Interface: Autodesk.Connectivity.JobProcessor.Extensibility.IJobHandler
ExtensionType in the .vcet.config: JobProcessor
Loads in: JobProcessor.exe

Web Service Command Extensions:

Description: Web Service Command extensions are for responding to events from any Vault client running on a computer.
Interface: Autodesk.Connectivity.WebServices.IWebServiceExtension
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.


Comments

7 responses to “What Makes a "Vault Extension"”

  1. hi!this is my first post in just one and zeros, i was wondering how to handle a multiple plug in scenario
    where those plugins shares a library who’s not in the GAC but it’s strong named.
    Whould it be possible to do an assembly load somewhere ?

  2. to add more details,
    I’m talking about the 2013 API and to me looks like adding to the class that implements the iExtension interface a constructor, that will be called.
    BUT unfortunately seems like that vault checks for all the reference the plugIn needs and if he can’t find all of them just does not load the plugin so no custom load is allowed … kinda of frustrating :(

  3. First, there is a way to see the load errors. http://justonesandzeros.typepad.com/blog/2012/07/extension-loading-error-logging.html
    Next, if your DLL references another DLL not in the GAC, you have a couple of options.
    You can copy the referenced DLLs to the same folder as your extension. But this only works if there are a few small DLLs.
    If you are dealing with a large API framework, you will have to remove all direct references in your project, and use one of the Assembly.Load functions instead. This makes your code much harder to work with, but it allows your DLL to load first before loading the references.
    I’m aware that DLL load paths are an issue, and the issues is being worked on.

  4. Actually i found a dirty solution, Since the nice ones where not working!
    I’ve created a new plugin who bind the appdomain.AssemblyLoad event to a function who scan what is being loaded and i managed to get it loaded first, when Vault try to load my plugin i do an assembly load of my libs…
    I think would be nice to understand if it is vault who’s checking for dependency to prevent crashes during later use (i think this is probable) or it’s the clr, so maybe in the next API the could give us an overridable function called LoadAssemblies who get called before the check… maybe
    Or a list of dll paths who vault can try to load and skip the plugin loading if some fails

  5. It’s the CLR that is preventing the load. The Vault framework attempts to fix things by manually loading from known locations, but it could be more robust.
    If you want to see what is being planned, sign up for the Beta and we can chat more. I put the invite link in today’s posting.

  6. Kamil Halas Avatar
    Kamil Halas

    Hello,
    As I understand Web Service Command Extension is loaded on any application which is using Autodesk.Connectivity.WebServices.dll.
    I have created such extension and it does load when Vault client is launched.
    But my extension doesn’t load when Inventor with Vault addin is launched.
    What can be wrong?
    Is Vault addin for Inventor use Autodesk.Connectivity.WebServices.dll?
    Regards,
    Kamil

  7. My first guess is that is a version issue. Events only work for a specific version. So if you build event handlers with the 2015 SDK, it will only work with the 2015 clients.
    See this article for more details: http://justonesandzeros.typepad.com/blog/2012/09/events-and-multiple-client-versions.html
    If that’s not the problem, have a look at this article on how to get more information. http://justonesandzeros.typepad.com/blog/2012/07/extension-loading-error-logging.html
    And yes, Inventor uses Autodesk.Connectivity.WebServices.dll.

Leave a Reply

Discover more from Autodesk Developer Blog

Subscribe now to keep reading and get access to the full archive.

Continue reading