Ok – now more details on policies.  NOTE:  The interfaces and methods listed below are NOT in concrete and may change slightly prior to shipping.

 

A policy can be configured to run each time a checkin is issued – either through the command line checkin or through Visual Studio.  To implement a policy, the developer must implement 2 interfaces:  IPolicyDefinition and IPolicyEvaluation.

 

There are two locations where policies can be accessed:  the first is during the configuration/installation of the policy.  To install the policy, you must first be in the admin group for a particular portfolio project.  Once in that group, you select to add a policy to this portfolio project (you may have any number of policies installed/configured for a portfolio project).  Once the policy is added to the portfolio project, you are able to configure the policy; since every policy is different, you (the implementer of the interfaces) are responsible for displaying a dialog for the user to configure; of course, if there is no configuration available for your policy, you can just ‘return’ from that method.  Once the configuration is complete, the policy is serialized and is sent to the server (Yukon database).  This functionality is coded when the IPolicyDefinition interface is implemented.

 

The second time the policy is accessed is during the actual checkin.  When checking in a file in the portfolio project where the policy is configured, the policy will be evaluated.  If the policy has a failure (or numerous failures), the policy will need to return the list of failures to be displayed in the policy toolwindow.  Also, you may subscribe to events to notify your policy when files are checked out (or checked/unchecked in Visual Studio Source Control toolwindow).  You may also notify Visual Studio when a policy fails without Visual Studio asking.  This functionality is coded when the IPolicyEvaluation interface is implemented.

 

To help explain how policies work, we will create a policy over the next couple postings.  The policy which we will create will verify that there are no tabs in specific files; here are the requirements for this policy:

-          Allow the administrator the ability to configure which file extensions should be scanned for tabs.

-          Using the configuration above, verify the policy fails for each file containing tabs.

-          If the user selects/un-selected files from the pending checkins toolwindow, verify those files are scanned for failures dynamically.

-          Once a file is being ‘watched’ for tabs, automatically add a failure to Visual Studio for that file if file is saved and contains tabs.

-          Once a file is being ‘watched’ for tabs, automatically remove failure from Visual Studio for that file if file is saved and no longer contains tabs.

 

To create this policy, we will do it in steps:

  1. Create framework with little functionality – basically, implement all necessary interfaces to allow policy to compile.
  2. Add to above policy which will now scan for tabs each time the checkin button is pressed – notifying user of failures (files which contain tabs) or continue with checkin if files do not contain tabs.  Hardcode which extension to verify tabs.
  3. Add to above policy to allow user to configure which extension to use.
  4. Add to above policy to receive events from Visual Studio when files are selected/un-selected from pending checkin toolwindow.  Also, watch these files add post failures (and remove failures) to Visual Studio depending on if tabs were added or removed from the file.