Share via

Untangling the Terminology

  • Article

Originally I was planning on jumping right into some gory details about security model when I realized that half of what I was saying is quite possibly illegible because of the terminology I use.  So I started a section of terminology that quickly exploded into something more than large enough to be its own post.  I won't claim that any of this terminology is industry standard, rather this is the way I refer to things and I am willing to consider revisions if better terms are presented to me.  So here’s a bit of terminology to help decrypt not only what I am saying but what I mean.

Developer

A developer is a person or group of people who use Visual Studio to produce programmatic functionality.  Additionally, I will for the most part bucket anyone involved the in process of production as part of the “developer” (ex.  A system Administrator who maintains the publish site is still consider part of the “developer” entity).  There are certain assumptions about knowledge and context I make when I talk about the developer that I may fail to specifically call out (ex. I assume a developer machine always has .NET and the appropriate VSTO runtimes installed).

User

Users are a person/people who consumes the product of the “developer”.  When I talk about users, I try to take the viewpoint of the most likely scenario (ex.  Most users are unlikely to know what VSTO or .NET is). 

VSTO

Visual Studio Tools for the Office system.

Solution

Generally I never talk about the Visual Studio solution project type (typified by the .sln file).  If I talk about a solution I often am talking about entire “application” that may contain many parts or programs.  An Example of a “simple” solution is a Add-in or a Customized Document plus it’s accompanied customization.  Solution is my generic term for “something a developer creates”.  It may be used interchangeably with project, but usually when I refer to project I refer to the Visual Studio project system type of project.

Customization

A customization is a (VSTO) “application” that alters some functionality of an Office application.  Customization is the most generic term applying to both Document and Application level functionality.  Something to

Add-in

An Add-in is a (VSTO) application level customization.  An add-in will run when the office Application is started unless it is disabled.  (It may be disabled temporarily because of special applications like Automation Mode or Headless (no UI) mode.   Or it may be disabled because of errors or user settings in the COM Add-ins Dialog)

Document Add-in / Document Customization /Customized Document

A document level add-in is a customization which is associated with a document rather than the application.  The functionality in the customization only runs when the associated document(s) are opened and will end execution when the document is closed.  Generally when talking about these types of projects I try to be clear about the parts.  The “customization” is the functionality part, which means that if I refer to the “customization of the document” I’m talking specifically about the following parts:  deployment manifest, application manifest, binary/resource artifacts.  I will refer to the document part as the “Customized Document”.  Currently only Excel and Word contain this type of customization. 

VSTOR3.0/VSTO Runtime 3.0

This refers to the VSTO Runtime that was published with Visual Studio 2008 that specifically targets Office 2007. 

VSTO 3 Customization/Add-in/Customized Document

VSTO3.0 Customization refers to customizations that run on the VSTOR3.0.   VSTO3.0 customizations currently are only available via Office 2007 (Office 12) Projects in Visual Studio 2008.

VSTO2.0/VSTO2.0 Customizations

This refers to any customizations built by Visual Studio 2005/ Visual Studio 2005 Second Edition and the subsequent runtime that they are associated with.  Office 2003 customizations in Visual 2008 are also VSTO2.0 customizations.  I will not cover these in depth, but I will occasionally point out major differences.

Trust Prompt

This is the dialog that comes up during installation of a VSTO3.0 Customization that asks the user if they trust the developer or location enough to install the customization.   The trust prompt is particularly notable in that it provides only verifiable information about the developer based on the certificate and location.  The Trust prompt does not contain “Trust / Don’t Trust” buttons but rather “Don’t Install / Install”.

Inclusion List

A VSTO trust decision storage mechanism.  Basically the inclusion list is a list of associated location paths and public keys used to associate trust to a specific customization.  The inclusion list has an API that can be used to add, query and remove trust entries.   When the Trust Prompt is clicked, an inclusion list entry is created by the VSTOR3.0 Runtime.

Certificate Trust

Certificate Trust refers to trust decisions made solely based upon the certificate used to sign the customization.  The trust decisions can be “Trusted” or “Un-Trusted” or “Not Trusted”.

Trusted/Un-Trusted/Not Trusted

There are basically 3 states of Trust for a VSTO solution to be in.  “Trusted” indicates that the solution is trusted and should be allowed to run.  “Un-Trusted” indicates that the solution is not trusted to such a degree that it should not run.  Both Trusted and Un-Trusted are the only final state a trust evaluation can come to.  However there is a state in-between Trusted and Un-Trusted that occurs during trust evaluation.  Not Trusted will specifically refer to the state of “Trust has not been determined.”  When the Trust Prompt comes up, the customization is in this state of “Not Trusted” until the user decides if the solution is “Trusted” or “Un-Trusted”.  I will try to be explicit about how I use these terms because it can be very confusing. 

I may occasionally come across a Term or two which also needs to be clarified.  In future posts I will tag such articles with the “Terminology” tag.

Thank You for Reading.

Kris

Comments