This article introduces Enterprise Template Policy Files. In this article, you will learn how policy files affect the configurable elements of the Visual Studio .NET IDE. You will learn about the Template Description Language Grammar Elements used in creating policy files. You will also learn about the "DAP.tdl" Policy File.
This series organizes around two central premises: first, this series teaches the fundamental concepts of Enterprise Templates; second, this series demonstrates how to implement Enterprise Templates using different Visual Studio .NET Project Types. This article series will primarily benefit two types of audiences: individuals curious about Enterprise Templates (with little knowledge or experience developing Enterprise Templates), and individuals familiar with the fundamental concepts of Enterprise Templates (but seeking a more application-oriented, tools-development approach to constructing Enterprise Templates).
The .NET Architect Enterprise Template Series will demonstrate how to build Enterprise templates and Policy Files using the following Visual Studio .NET projects:
The Visual Studio .NET Add-In Project
The Visual Studio .NET Web Service Project
The Visual Studio .NET Windows Service Project
The Visual Studio .NET Web Control Project
Enterprise Template Editor Windows Control
Enterprise Template Editor Framework
(To my loyal readers, please note my new e-mail address: VBAnswerGuy@adelphia.net. If you are interested my book on VB.NET, or C#, please write me and ask for a sample chapter when completed.)
Requirements
Visual Studio.NET Enterprise Developer, or Enterprise Architect Edition
Section 1: Introduction
Section 2: Policy File Overview
Section 3: Policy File Validation
Section 4: Policy File Grammar
Section 5: The "DAP.tdl" File
Summary
About the Author
Section 1: Introduction
The .NET Enterprise Template series covers the fundamental concepts of Enterprise Template design, development, and deployment. In this article, you will learn about Enterprise Template Policy Files as they relate to Visual Studio .NET Enterprise Template Development. This article explains the role of Policy Files in large, distributed organizations that use Enterprise Templates. To create Enterprise Templates, and Enterprise Template Policy Files, you must have either the Visual Studio .NET Enterprise Developer or Visual Studio .NET Enterprise Architect Edition installed on your computer.
Software systems are typically modeled using methodologies such as UML (the Universal Modeling Language) and ORM (Object Role Modeling). They are constructed using various development methodologies such as Extreme Programming and the Microsoft Solutions Framework Team Programming Model, which is part of the Microsoft Solutions Framework. Each approach generates a large number of software artifacts. These artifacts are typically re-used among other development initiatives within an organization. Software artifacts are categorized, classified, and archived for later use. New applications can access your repository of reusable artifacts to eliminate duplicating the functionality of your pre-existing software components.
A common barrier to building complex distributed enterprise applications is in labeling, locating, and understanding the artifact's proper use within the contextual framework of an organization's policies, procedures, and coding standards. Microsoft created Visual Studio .NET Enterprise Templates to help make the identification, selection, and implementation of reusable software artifacts transparent to developers; to effectively integrate common boilerplate source code for common types of developed applications; and to abstract developers from the complexities and rules of their organization's software development coding standards, procedures, and best-practices. Enterprise Template Policy Files organize pre-existing software artifacts into a structure that models the type of baseline application to be built and restrict the types of artifacts that may be part of the current application. This article describes how Policy Files abstract you from the details of conforming to your company's software development best-practices and architectural guidelines. A high-level overview of the "DAP.tdl" file structure and the "Vside.tdl" file structure is also provided.
The .NET Architect Enterprise Template Series comprises the following articles:
Article 8: Enterprise Template Editor Windows Service
Article 9: Enterprise Template Editor Web Control
Article 10: Enterprise Template Editor Windows Control
Article 11: Enterprise Template Editor Framework
Article 12: Enterprise Template Developer Notes
Section 2: Policy File Overview
Enterprise Template Policy Files have a ".tdl" extension. Policy Files are designed, customized, and associated with an Enterprise Template Project file (".etp" file). When users create a project based upon an Enterprise Template, its associated policy file is parsed and loaded into memory; the individual Enterprise Template Projects, and Enterprise Template Language Projects, are loaded into a Visual Studio .NET Solution; finally, the customizable items of the Visual Studio .NET IDE are configured according to their corresponding policy file configuration settings.
"Dap.tdl" and "Vside.tdl" are the two main Visual Studio .NET Enterprise Template Policy Files. Policy Files primarily affect the configurable elements of Visual Studio .NET such as the Task List, the Properties Window, the Add New Project Dialog Box, the Add New Item Dialog Box, the Toolbox, the Menus, and the Dynamic Help Window. Policy Files also affect primary IDE processes such as drag and drop and cut and paste. When an Enterprise Template is opened, the associated Policy File is parsed and applied to the Visual Studio .NET IDE, resulting in a development environment custom configured for the chosen development task.
Policy Files use Template Services to communicate configuration information to various Visual Studio .NET IDE elements. These elements include the Task List, Toolbar, Property Browser, Project Explorer, Dynamic Help Window, and any Designers or Editors. To configure an IDE element, Template Services send configuration messages to the target IDE element. To configure the Task List, the Policy File sends "Policy Reminder" messages to the .NET IDE. To configure the Toolbox, the Policy File sends "Control Constraint" messages to the .NET IDE. To configure the Property Browser, the Policy File sends "Property Constraint" messages to the .NET IDE. To configure the Project Explorer, the Policy File sends "Project Structure" messages to the .NET IDE. To configure the Dynamic Help Window, the Policy File sends "Selection Context" messages to the .NET IDE. Finally, to configure the Visual Studio .NET Designers and Editors, the Policy File sends "Launch & Configure" messages to the IDE. Figure 1.0 illustrates the relationships just mentioned.
IDE Object
Message
Task List
Policy Reminders
Toolbox
Control Constraints
Property Browser
Property Constraints
Project Explorer
Project Structure
Dynamic Help Window
Selection Context
Designers & Editors
Launch & Configure
(figure 1.0)
Section 3: Policy File Validation
An Enterprise Template Project agrees to be bound by its associated policy file constraints. The process of determining if an Enterprise Template follows the directives of its Policy File is called Policy File Validation. Validation is initiated when projects, folders, and other items are added, deleted, or rearranged within the current project hierarchy.
The policy file validation process begins when a change occurs to the active solution in the Visual Studio .NET Solution Explorer. Each solution item in the Solution Explorer is mapped to a specific tag in the project's policy file. When an item is modified in the Solution Explorer, the item's associated tag is consulted to determine if the attempted modification is allowable and if the modification conforms to the restrictions listed in the policy file. If the change is an allowable modification, the change is applied to the solution item or the modification is made. If the change is a forbidden modification, the change is not applied to the solution item and the modification is not made.
A policy file validation error occurs when policy file syntax is incorrect. A policy file conflict error occurs when an attempted modification of a solution item is rejected. Policy File Validation Errors and Conflict Errors are processed differently. When a policy file validation error occurs, two solutions exist to fix the error: you can correct the offending policy file setting or you can modify the solution item that triggered the validation error. When a policy file conflict error occurs, there is typically more than one <ELEMENT> node defining the same value for the same property or feature. When conflict errors occur, the rejected solution item's policy is not applied and the conflict error is listed in the Task List. Pay careful attention to designing your Enterprise Templates and associated Policy Files - this will help decrease the amount of conflicting errors when enforcing policy file constraints against specific solution projects and items.
Section 4: Policy File Grammar
Enterprise Template Policy Files are constructed using an XML Grammar that defines the projects, items and constraints that encompass the policy definition. Figure 2.0 represents the available grammar elements for constructing Enterprise Templates and Policy Files. The collection of grammar elements used to define Enterprise Templates is collectively referred to as the Template Definition Language (TDL). You will learn more about the Enterprise Template Definition Language Grammar Elements (TDL) in article three titled, "Enterprise Template TDL Language."
Template Definition Language (TDL) Grammar Elements
The DAP.tdl file is one of the most important Policy Files. For a typical Visual Studio .NET installation, the DAP.tdl file is located in the "C:\Program Files\Microsoft Visual Studio .NET\Enterprise Frameworks\Policy" directory. We will now recursively decompose and examine the conceptual structure of the DAP.tdl file.
The main container elements of the DAP.tdl file begin in line #2, #10, #62, and #66, the <DEFAULTSETTINGS>, <ELEMENTS>, <CATEGORIES>, and <FEATURES> elements respectively.
<TDL>
The <TDL> element is the root element of a policy file. Only one <TDL> element may exist in any Policy File. All policy file grammar elements must be contained within the bounds of the <TDL> element.
<DEFAULTSETTINGS>
The <DEFAULTSETTINGS> block has the following signature:
The <DEFAULTSETTINGS> block defines default behaviors and constraints for the <ELEMENT> and <ELEMENTSET> nodes contained within the DAP.tdl Policy File. Specifying default settings for newly created <ELEMENT> and <ELEMENTSET> nodes allows Enterprise Template Designers to customize only those policy file nodes that require specific modifications - all other nodes will inherit the default settings from the <DEFAULTSETTINGS> block. In the next article titled, "Enterprise Template TDL Language", the Template Description Language Grammar Elements in lines #1-#9 will be discussed.
<ELEMENTS>
The <ELEMENTS> block has the following signature:
The <ELEMENT> node defines the configuration information for a single item in the DAP.tdl Policy File. Major <ELEMENT> children include the <ID>, <CONTEXT>, <IDENTIFIERS>, <FEATURELINKS>, <PROTOTYPES>, <CONSTRAINTS>, and <ELEMENTSET> nodes. By examining the structure above, you may be asking, "If every <ELEMENT> node requires this verbose structure, will the final size of the DAP.tdl file be very large?" - The answer is YES! - Since the DAP.tdl File is Element Normalized XML, printing the entire DAP.tdl file would require about 88 pages! The final size of the DAP.tdl file depends upon several factors, including the number of items configured and the types of limitations imposed upon the project structure. In the next article titled, "Enterprise Template TDL Language", the Template Description Language Grammar Elements in lines #11-#61 will be discussed.
<CONTEXT>
The <CONTEXT> block has the following signature:
The Dynamic Help Window of the Visual Studio .NET IDE provides real-time help when IDE elements are selected. When an IDE element is selected, the element is said to have the active context. If an IDE element contains help that should be displayed in the Dynamic Help Window when the element has the active context, the <ELEMENT> tag in the DAP.tdl Policy File will contain a <CONTEXT> node.
<CTXTATTRIBUTE>
The <CTXTATTRIBUTE> block has the following signature:
15:<CTXTATTRIBUTE> 16:<NAME> 17:<VALUE>
(figure 9.0)
When the Dynamic Help Window displays real-time, contextual help, it needs to know the list of help files it should display. The contextual boundaries of the help files displayed for the selected Visual Studio .NET IDE element is configured by setting the values of the <CTXTATTRIBUTE> element of the <ELEMENT>.
<IDENTIFIERS>
The <IDENTIFIERS> block has the following signature:
When the Visual Studio .NET IDE loads and parses your Policy Files, it needs to identify, locate, and load your project's components. The <IDENTIFIERS> node contains a collection of the components available from within your Policy File.
<IDENTIFIERDATA>
The <IDENTIFIERDATA> block has the following signature:
21:<IDENTIFIERDATA> 22:<NAME> 23:<VALUE>
(figure 11.0)
The <IDENTIFIERDATA> node contains a name/value pair describing the type of its parent element. When referencing a type or a class, you must use the fully qualified name of the resource including its namespace. Without the full qualification, the Policy File cannot correctly map your component and its type to the CLR component.
<FEATURELINKS>
The <FEATURELINKS> block has the following signature:
Policy Files often restrict access to menu and toolbox items. The <FEATURELINKS> node contains a collection of toolbox and menu items that will be restricted. The menu and toolbox items are restricted by an ID which identifies the IDE element to Visual Studio .NET.
<MENULINKS>
The <MENULINKS> block has the following signature:
25:<MENULINKS> 26:<MENULINK>
(figure 13.0)
Each menu item available within the Visual Studio .NET IDE has an associated menu ID. This ID identifies the menu item as unique. To enable or disable a menu item from within a DAP.tdl Policy File, you explicitly inform the .NET IDE which menu items you want restricted. In essence, when a specific element is selected in the IDE, you can show or hide, and enable or disable specific menu items.
<TOOLBOXLINKS>
The <TOOLBOXLINKS> block has the following signature:
27:<TOOLBOXLINKS> 28:<TOOLBOXLINK>
(figure 14.0)
When the selected item changes inside the Visual Studio .NET IDE, you can control which toolbox elements the user can access. To control which toolbox elements should be associated to the currently selected IDE element, you include those elements as children of the <TOOLBOXLINKS> node. As you change the currently selected IDE element, the toolbox will enable or disable the proper items.
<PROTOTYPES>
The <PROTOTYPES> block has the following signature:
29:<PROTOTYPES> 30:<PROTOTYPE>
(figure 15.0)
If a node already exists, you can clone its existing definition instead of re-recreating the node and all its children. To clone a previously existing node and all its children, you define a <PROTOTYPE> node, which is contained within the <PROTOTYPES> node. This prototype functions as a template upon which to base new <ELEMENT> nodes.
<CONSTRAINTS>
The <CONSTRAINTS> block has the following signature:
While interacting with the Visual Studio .NET IDE, focus shifts from one user interface element to the next. The currently selected user interface element maintains the IDE context - the IDE element with the focus. Enterprise Template Policy Files allow you to enable or disable IDE settings when shifting focus among IDE elements. The <CONSTRAINTS> node defines and manages IDE settings for specific nodes.
<PROPERTYCONSTRAINTS>
The <PROPERTYCONSTRAINTS> block has the following signature:
Selecting a Visual Studio .NET IDE element to work with exposes certain configurable properties to the user. These properties display in the Properties Window. You are able to restrict how each property displays by applying property constraints to the element using the <PROPERTYCONSTAINTS> node. <PROPERTYCONSTRAINTS> is the parent of the <PROPERTYCONSTRAINT> node, which defines the actual contextual element restrictions.
<PROPERTYCONSTRAINT>
The <PROPERTYCONSTRAINT> block has the following signature:
When an IDE element contains the current focus, it has the current context as well. To restrict the properties of the element, you apply policy to the selected element, which is contained within a <PROPERTYCONSTRAINT> node definition.
<MENUCONSTRAINTS>
The <MENUCONSTRAINTS> block has the following signature:
Selecting a Visual Studio .NET IDE Menu Item triggers an action. Upon selecting a specific menu item, you might want other menu items to be enabled or disabled based upon the context of the currently selected menu item. To constrain menu items based upon the menu item containing the focus, restrict these elements by configuring the <MENUCONSTRAINTS> node.
<MENUCONSTRAINT>
The <MENUCONSTRAINT> block has the following signature:
40:<MENUCONSTRAINT> 41:<ID> 42:<ENABLED>
(figure 20.0)
Specific menu items may be enabled or disabled based upon the specific type of Enterprise Template Project to be modified. To restrict access to a menu item, the <MENUCONSTRAINT> node is configured once for each menu item to restrict.
<TOOLBOXCONSTRAINTS>
The <TOOLBOXCONSRAINTS> block has the following signature:
In addition to menu items, you might also want users of your Enterprise Templates to have restricted access to certain types of components in the toolbox. To create restricted toolbox items, add a <TOOLBOXCONSTRAINTS> node in your Policy File.
<TOOLBOXCONSTRAINT>
The <TOOLBOXCONSRAINT> block has the following signature:
44:<TOOLBOXCONSTRAINT> 45:<ID> 46:<ENABLED>
(figure 22.0)
Each toolbox item to be restricted must have an associated <TOOLBOXCONSTRAINT> node in the Policy File. The <ID> node contains the ProgID of the menu item as Visual Studio .NET knows it, while the <ENABLED> node determines if the toolbox item has restricted access.
<ELEMENTSET>
The <ELEMENTSET> block has the following signature:
The <ELEMENTSET> node allows you to group element nodes of like functionality. You may then further refine and restrict these elements based upon your customized requirements.
<CONSTRAINTS>
The <CONSTRAINTS> block has the following signature:
While interacting with the Visual Studio .NET IDE, focus shifts from one user interface element to the next. The currently selected user interface element maintains the IDE context - the IDE element with the focus. Enterprise Template Policy Files allow you to enable or disable IDE settings when shifting focus among IDE elements. The <CONSTRAINTS> node defines and manages IDE settings for specific nodes.
<MEMBERCONSTRAINTS>
The <MEMBERCONSTRAINTS> block has the following signature:
When grouping similar functional nodes using the <ELEMENTSET> node, the <MEMBERCONSTRAINTS> node allows you to refine a subset of those restrictions contained within the bounds of an <ELEMENTSET> node.
<MEMBERCONSTRAINT>
The <MEMBERCONSTRAINT> block has the following signature:
A single <MEMBERCONSTRAINT> node will restrict the functionality of an <ELEMENTSET> node member. The restrictions applied using the <MEMBERCONSTRAINT> nodes primarily apply to Visual Studio .NET IDE elements. Restricting an IDE element requires knowing the IDE element ID as well as what type of restriction to place upon the element.
<CATEGORIES>
The <CATEGORIES> block has the following signature:
The <CATEGORIES> node is one of the four primary child nodes of the <TDL> element. It contains <CATEGORY> nodes, which are aliases for common nodes in your templates. This keeps you from repetitive definition of similar element types.
<CATEGORY>
The <CATEGORY> block has the following signature:
63:<CATEGORY> 64:<ID> 65:<CATEGORYMEMBER>
(figure 28.0)
The <CATEGORY> element is a container for aliasing a group of <ELEMENT> nodes, as mentioned above. For example, you could create a grouping of HTML type projects or create a grouping of Middle-Tier type projects referenced by a single easily remembered name.
<FEATURES>
The <FEATURES> block has the following signature:
Use the <FEATURES> element for contextually enabling and disabling access to specific Visual Studio .NET menus and toolbox items. When a user selects a project item to modify, you might also want the user to have restricted access to a menu that would allow negative consequences if used incorrectly. The <FEATURES> element will be commonly used in your own Enterprise Template Projects.
<MENUS>
The <MENUS> block has the following signature:
67:<MENUS> 68:<MENU> 69:<ID> 70:<CMDID> 71:<GUID>
(figure 30.0)
Contextually restricting access to specific Visual Studio .NET menus and menu items requires the existence of a <MENU> node. We will look at this next. For now, think of the <MENUS> node as a simple container for the <MENU> items restricted via policy.
<MENU>
The <MENU> block has the following signature:
68:<MENU> 69:<ID> 70:<CMDID> 71:<GUID>
(figure 31.0)
The <MENU> Element defines the specific instance of the Visual Studio .NET IDE menu item to restrict using policy. To see a listing of all available menu items exposed to you, see the "Vside.tdl" policy file. As an example of controlling menu items, like the "Edit->Cut" menu item, the TDL might look something like this:
Like the <MENU> element, the <TOOLBOXITEMS> element contains a list of <TOOLBOXITEM> elements to restrict via policy. Nothing more to be said.
<TOOLBOXITEM>
The <TOOLBOXITEM> block has the following signature:
73:<TOOLBOXITEM> 74:<ID> 75:<DESCRIPTOR>
(figure 33.0)
The <TOOLBOXITEM> represents a single instance of a specific toolbox item, such as the HTMLLabel Control, to restrict using policy. It is important to note, that restrictions to IDE Elements such as menus and toolbox items only have meaning in the context in which they are resticted.
Summary
A common barrier to building complex, distributed enterprise applications is in labeling, locating and understanding the artifact's proper use within the contextual framework of an organization's policies, procedures and coding standards. Microsoft created Visual Studio .NET Enterprise Templates to help make the identification, selection and implementation of reusable software artifacts transparent to developers; to effectively integrate common, boilerplate source code for common types of developed applications; and to abstract developers from the complexities and rules of their organization's software development coding standards, procedures and best-practices. Enterprise Template Policy Files organize pre-existing software artifacts into a structure that models the type of baseline application to be built, and restricts the types of artifacts may be part of the current application.
"Dap.tdl" and "Vside.tdl" are the two main Visual Studio .NET Enterprise Template Policy Files. Policy Files primarily affect the configurable elements of Visual Studio .NET such as the Task List, the Properties Window, the Add New Project Dialog Box, the Add New Item Dialog Box, the Toolbox, the Menus, and the Dynamic Help Window. Policy Files also affect primary IDE processes such as drag and drop and cut and paste. When an Enterprise Template is opened, the associated Policy File is parsed and applied to the Visual Studio .NET IDE, resulting in a development environment custom configured for the chosen development task.
An Enterprise Template Project agrees to be bound by its associated policy file constraints. The process of determining if an Enterprise Template follows the directives of its Policy File is called Policy File Validation. Validation is initiated when projects, folders, and other items are added, deleted, or rearranged within the current project hierarchy.
A policy file validation error occurs when policy file syntax is incorrect. A policy file conflict error occurs when an attempted modification of a solution item is rejected. When a policy file validation error occurs, two solutions exist to fix the error: you can correct the offending policy file setting or you can modify the solution item that triggered the validation error. When a policy file conflict error occurs, there is typically more than one <ELEMENT> node defining the same value for the same property or feature.
Enterprise Template Policy Files are constructed using an XML Grammar that provides the projects, items, and constraints that comprise the policy definition.
About the Author
Brian has worked in the Information Technology profession since 1995. He currently lives in Colorado Springs, Colorado with his wife and family. He enjoys road trips, hiking, fishing, and spending time in the mountains of Colorado. Brian worked for Microsoft as an ASP.NET Support Engineer during the worldwide launch of Visual Studio .NET. While at Microsoft, Brian developed an interest in researching .NET Language Development, .NET Windows Services, and IDE programmer productivity add-ins. He is writing textbooks for teaching C# and VB.NET to aspiring developers. If you interested in his book, please contact him at: VBAnswerGuy@adelphia.net.
In this article, Joseph Poozhikunnel examines the importance of the three X's -- namely XML, XML Schema, and XSLT -- in a service oriented architecture (SOA). He then defines the design considerations that need to be adopted when designing a system based on SOA and examines the pitfalls that can arise if they're not followed.
[Read This Article][Top]
In this article, Joseph Poozhikunnel defines an Enterprise Service Bus (ESB) that can be created to support any Service Oriented Architecture (SOA) adopted by an organization. The type of ESB required could vary as there is no "one size fits all", therefore the article examines a few of the mechanisms available that could be adopted to implement an ESB. [Read This Article][Top]
In the seconmd part of his series on building an end user defined data model, Peter Scheffler gets into the actual meat of the model and discusses real-world implementation details and the actual table layouts. [Read This Article][Top]
In the first article in this series, Peter Scheffler introduces the concept of a rules-based database engine that allows clients to make changes to their database structure without breaking the applications that access the database. [Read This Article][Top]
The basic premise of a Service Oriented Architecture (SOA) system is to decouple applications from each other in order to make them autonomous. In this article, Joseph Poozhikunnel presents a simple SOA framework that can be used as a starting point for a system that addresses your specific business needs. [Read This Article][Top]
A well rounded versioning and deployment strategy considers several overlapping and interdependent .NET Framework concepts. In this article, Michele Leroux Bustamante will take you through a ten step program that reviews these core concepts, their relationship, and provides guidance for successful application deployments for the .NET Framework. [Read This Article][Top]
Adnan Masood continues his discussion of Microsoft SQL Server Analysis
services and Microsoft SQL Server Reporting services. In this part, he
discusses the steps that go into building more advanced reports. [Read This Article][Top]
Adnan Masood discusses Microsoft's comprehensive integrated business
intelligence, data mining, analysis and reporting solution: Microsoft SQL
Server Analysis services and Microsoft SQL Server Reporting services. [Read This Article][Top]
Chip Irek examines the architectural issues and component design issues of building a .NET application in a service-oriented architecture. [Read This Article][Top]
The importance of reuse can't be overstated, especially in light of the
degree to which we go out of our way to avoid it, but implementing a reuse strategy means creating high-quality low-cost applications that just might save your job. [Read This Article][Top]
Mailing List
Want to receive email when the next article is published? Just Click Here to sign up.
