Export (0) Print
Expand All

Walkthrough: Applying Constraints in an Enterprise Template Policy File

Visual Studio .NET 2003

Using constraints to provide guidance to a development team is an advantage for architects of any Enterprise Template application. Constraints relieve developers of the need to make certain programming decisions, which decreases their need to study or otherwise assimilate instructional information.

In this walkthrough, you work with a variety of scenarios to learn how to apply constraints that improve the usability of the Visual Studio integrated development environment (IDE) for development teams on your particular projects.

This walkthrough contains the following sections:

Before You Begin this Walkthrough

Scenario One: Disabling a menu item for an entire application

Scenario Two: Disabling a menu item for everything except a particular project

Scenario Three: Disabling a Menu Item associated with an Element

Scenario Four: Disabling Toolbox Items everywhere

Scenario Five: Setting up standard values for OleDbConnection String, Timeout

Scenario Six: Specifying UI standards

Before You Begin this Walkthrough

Before performing the steps in this walkthrough, complete the steps in Walkthrough: Creating a New Enterprise Template. By creating a new Enterprise Template, you learn about implementing policy by using the Template Description Language (TDL), and you can familiarize yourself with the file types required in this walkthrough. You also create files that you will use in this walkthrough.

Print the Walkthrough

Print this walkthrough to simplify its use. This is particularly helpful if you are using a single machine to read the instructions and carry them out. You will be typing or copying and pasting a significant amount of text and the easiest approach is to open and print the walkthrough. Keep the walkthrough open but use the hard copy to follow the instructions. When it is necessary to copy-and-paste a block of text, switch to the walkthrough, find and copy the needed lines, and then paste them where appropriate.

Another option for viewing this topic as you work is to display Help outside of the Visual Studio integrated development environment (IDE). On the Tools menu, select Options. Choose Help from the Environment folder, and then choose External help on the Help Settings page. Note that changes made on the Settings page do not take effect until the integrated development environment (IDE) is restarted.

Summary of Constraints and How They Apply

Enterprise Templates supports constraints of three different types:

  • Menu constraints
  • Toolbox constraints
  • Property constraints

For menu and Toolbox items, an item can be disabled in a particular context.

For properties that appear in the Properties window, a property value can be constrained in any of three ways:

  • It can be set to read-only.
  • It can be set to a particular value.
  • It can be set to check for a range of recommended values.

The degree to which a constraint affects the options available to developers is the scope of that constraint. The concept of scoping at different levels is central to providing precise guidance to a development team. You can set the constraints listed above at one of several scoping levels.

Constraints at narrower scoping levels override constraints imposed at the broader levels. For example, a member-specific constraint overrides any constraint imposed at a broader level. Constraints are applied based on the current selection in Solution Explorer or within a designer. Property constraints on items within a designer are applied when the containing project item is opened in the designer. (For example, when a form is opened in the designer, all controls on the form are checked for property constraints.) For more information, see Constraint Scoping Levels.

Scenario One: Disabling a menu item for an entire application

You might need to make one or more menu items unavailable for developers working on an application. This scenario works with menu items that are not associated with an ELEMENT, such as Build.DeploySolution and Tools.AddInManager. If you want to disable a menu item for any selection in a policied application, the easiest way to accomplish this is using a default constraint.

Note   If you select the Solution node in the Solution Explorer, you are outside of the policied project and no policy restrictions or guidance apply.

To specify a default constraint, add the appropriate type of constraint within the DEFAULTSETTINGS section of the policy file. The following procedure disables the New Folder menu item on the Project menu:

To disable a menu item in an application using a constraint

  1. Open the project created during Walkthrough: Creating a New Enterprise Template, MyTemplate. In Solution Explorer, select the UtilityProjects node and notice that on the Project menu, New Folder is enabled.
  2. Close the solution.
  3. Open MyPolicy.tdl (C:\Program Files\Microsoft Visual Studio .NET 2003\EnterpriseFrameworks\Policy\MyPolicy.tdl) and add the CONSTRAINTS node indicated in bold below to the DEFAULTSETTINGS section of the policy file.
    <DEFAULTSETTINGS>
        <DEFAULTACTION>INCLUDE</DEFAULTACTION>
        <ORDER>EXCLUDEINCLUDE</ORDER>
        <POLICYMODE>RESTRICTIVE</POLICYMODE>
        <CONSTRAINTS>
            <MENUCONSTRAINTS>
                <MENUCONSTRAINT>
                    <ID>menuProject.NewFolder</ID>
                    <ENABLED>0</ENABLED>
                 </MENUCONSTRAINT>
              </MENUCONSTRAINTS>
       </CONSTRAINTS>
    </DEFAULTSETTINGS>
    
  4. Save the changes and close the policy file.
  5. Reopen the MyTemplate project. Select UtilityProjects or any of the other ETP projects within Solution Explorer, right-click, and note that the New Folder menu item is disabled.
  6. Close the solution.
Note   You must have previously defined the menu item in the MENUS node of the FEATURES node in the policy file before you can apply a constraint to it. The Vside.tdl file that ships with Visual Studio contains definitions for all standard Visual Studio menu items. The definition for the above menu item looks as follows:
<MENU>
    <ID>menuProject.NewFolder</ID>
    <CMDID>245</CMDID>
    <GUID>{5EFC7975-14BC-11CF-9B2B-00AA00573819}</GUID>
</MENU>

Examples of menus associated with an ELEMENT would be Add Windows Form and Add Web Form. For more information about constraining that kind of menu item, see Scenario Three: Disabling a Menu Item associated with an Element.

Scenario Two: Disabling a menu item for everything except a particular project

You might encounter situations in which you want to disable menu items in every project of your application but one. To continue the example given in Scenario One: Disabling a menu item for an entire application, assume that you need to allow the creation of folders only within the UtilityProjects section of the application.

To override a default constraint

  1. To override the default constraint and allow developers to create folders within the UtilityProjects project, open the policy file (C:\Program Files\Microsoft Visual Studio .NET 2003\EnterpriseFrameworks\Policy\MyPolicy.tdl) for UtilityProjects. In the etpUtilityProjects ELEMENT definition, add a MENUCONSTRAINT enabling the New Folder menu item, as shown in bold below:
    <ELEMENT>
        <ID>etpUtilityProjects</ID>
        <IDENTIFIERS>
            <IDENTIFIER>
                <TYPE>PROJECT</TYPE>
                <IDENTIFIERDATA>
                    <NAME>GLOBAL:TDLELEMENTTYPE</NAME>
                     <VALUE>etpUtilityProjects</VALUE>
                </IDENTIFIERDATA>
            </IDENTIFIER>
        </IDENTIFIERS>
        <CONSTRAINTS>
            <MENUCONSTRAINTS>
                <MENUCONSTRAINT>
                    <ID>menuProject.NewFolder</ID>
                    <ENABLED>1</ENABLED>
                </MENUCONSTRAINT>
            </MENUCONSTRAINTS>
        </CONSTRAINTS>
        <ELEMENTSET>
            <DEFAULTACTION>EXCLUDE</DEFAULTACTION>
            <ORDER>INCLUDEEXCLUDE</ORDER>
            <INCLUDE>projUtilityLibrary</INCLUDE>
            <INCLUDE>projOptionalProject</INCLUDE>
            <INCLUDE>projCSharpClassLibrary</INCLUDE>
            <INCLUDE>projCSharpEmptyProject</INCLUDE>
        </ELEMENTSET>
        <PROTOTYPES>
            <PROTOTYPE>
            [EF]\Projects\MyTemplate\UtilityProjects\UtilityProjects.etp
            </PROTOTYPE>
        </PROTOTYPES>
    </ELEMENT>
    
    Note   You typically specify an ENABLED node with a value of 1 only when overriding a constraint set at a more general scope, as this example shows. For more information, see ENABLED and MENUCONSTRAINTS.
  2. Save and close the policy file.

To see the effect of the constraint defined in the preceding example

  1. Reopen MyTemplate (For details on creating this application, see Walkthrough: Creating a New Enterprise Template.)
  2. In Solution Explorer, select any node other than UtilityProjects, noting that the New Folder menu item on the Project menu remains disabled.
  3. Select the UtilityProjects node, noting that the New Folder menu item on the Project menu is enabled.
  4. Close the solution.

Scenario Three: Disabling a Menu Item associated with an Element

You can enable or disable a menu item that corresponds to a defined ELEMENT. For example, the Add Windows Form menu item is tied to the codeWinForm element. If you allow the codeWinForm element to be added to a project, the corresponding menu item is enabled. If you disallow the codeWinForm ELEMENT from being added to a project, the corresponding Add Windows Form menu item is disabled.

You can disable a menu item two ways: either including a FEATURELINK node within an ELEMENT definition or using a MENUCONSTRAINT in the DEFAULTSETTINGS node.

If the location where the menu item is allowed is easily defined using an ELEMENTSET, it is better to use a FEATURELINK associated with an included or excluded ELEMENT than to use a MENUCONSTRAINT.

However, if you want to exclude an item globally, it is easier to provide a MENUCONSTRAINT in the DEFAULTSETTINGS node to disable the menu item than it is to visit all the ELEMENTSET definitions. Note that you might want to do both, as only ELEMENTSET restrictions catch the case where the user adds the item via the Add Existing command and circumvents the menu constraint.

For more information on specifying a default constraint, see Scenario One: Disabling a menu item for an entire application. For more information on using ELEMENTSET nodes to control what can be added to various parts of an application, see Using ELEMENTSET Nodes to Specify Constraints in Policy Files.

Scenario Four: Disabling Toolbox Items everywhere

Toolbox constraints are very similar to menu constraints. One key difference is that, typically, every Toolbox item has an associated ELEMENT definition. In general, if the context in which you want to disable the Toolbox item can be defined easily using an ELEMENTSET, then using the ELEMENTSET definition and FEATURELINKS is the best way of disabling the Toolbox item. For more information, see Restricting Additions to an Application Through ELEMENTSET Nodes.

However, if you want to disable a Toolbox item for the entire application, you can do so in the same way as for menu items, by providing a default constraint. For example, the following steps disable the SQLConnection Toolbox item.

To disable a Toolbox item

  1. Open MyTemplate. (For details on creating this application, see Walkthrough: Creating a New Enterprise Template.) In Solution Explorer, expand the WinApp project and double-click Form1.cs to open it in the designer.
  2. In the Toolbox, view the Data tab and note that SQLConnection is enabled.
  3. Close the solution.
  4. Edit the DEFAULTSETTINGS node in MyPolicy.tdl to include a TOOLBOXCONSTRAINT disabling tboxDataSQLConnection, as shown in bold below:
    <DEFAULTSETTINGS>
        <DEFAULTACTION>INCLUDE</DEFAULTACTION>
        <ORDER>EXCLUDEINCLUDE</ORDER>
        <POLICYMODE>RESTRICTIVE</POLICYMODE>
        <CONSTRAINTS>
            <TOOLBOXCONSTRAINTS>
                <TOOLBOXCONSTRAINT>
                    <ID>tboxDataSQLConnection</ID>
                    <ENABLED>0</ENABLED>
                </TOOLBOXCONSTRAINT>
            </TOOLBOXCONSTRAINTS>
        </CONSTRAINTS>
    </DEFAULTSETTINGS>
    
  5. Save the changes to MyPolicy.tdl.
  6. Reopen the MyTemplate application, viewing the Toolbox once again. Note that SQLConnection is now disabled.
  7. Close the solution.

Note that although this disables the Toolbox item, it does not prevent the user from adding the SQLConnection Toolbox item another way, such as by adding code or by adding an existing item that contains SQLConnection. To make your restriction more effective, you should also disallow the codeDataSQLConnection element from the appropriate ELEMENTSET. For more information, see Restricting Additions to an Application Through ELEMENTSET Nodes.

Scenario Five: Setting up standard values for OLE DB Connection String

Enterprise Template Policy also provides the ability to specify constraints on properties that display in the Property Browser. For any property that displays in the property browser, it is possible to:

  • Make the property read-only
  • Specify the value that the property should always have (this also makes it read-only)
  • Specify a range of allowed values or simply a minimum value or maximum value

Once the ELEMENT is defined in the policy file, if you want these constraints to apply to any OleDbConnection items used in your application, you must provide an ELEMENT-level constraint, as shown in the following example.

To set ELEMENT-level constraints on properties

  1. Open the application to observe its current functionality.
    1. Open MyTemplate. (For details on creating this application, see Walkthrough: Creating a New Enterprise Template.) In Solution Explorer, expand the WinApp project and double-click Form1.cs to open it in the designer.
    2. Drag an OleDbConnection object onto the form. Select the OleDbConnection object and examine the Properties window, specifically the ConnectionString property. Note that you can change it without restriction.
    3. Delete the OleDbConnection object.
    4. Close the solution.
  2. Edit MyPolicy.tdl, to include a ConnectionString PROPERTYCONSTRAINT in the codeOleDbConnection ELEMENT definition, as shown in bold below:
    <ELEMENT>
        <ID>codeDataOleDbConnection</ID>
        <IDENTIFIERS>
            <IDENTIFIER>
                <TYPE>CODEVARIABLE</TYPE>
                <IDENTIFIERDATA>
                    <NAME>TYPENAME</NAME>
                    <VALUE>System.Data.OleDb.OleDbConnection</VALUE>
                </IDENTIFIERDATA>
            </IDENTIFIER>
        </IDENTIFIERS>
        <FEATURELINKS>
            <TOOLBOXLINKS>
                <TOOLBOXLINK>tboxDataOleDbConnection</TOOLBOXLINK>
            </TOOLBOXLINKS>
        </FEATURELINKS>
        <CONSTRAINTS>
            <PROPERTYCONSTRAINTS>
                <PROPERTYCONSTRAINT>
                    <NAME>ConnectionString</NAME>
                    <DEFAULT>Provider=SQLOLEDB.1;Integrated
                             Security=SSPI;Persist Security 
                             Info=False;Initial Catalog=pubs;Data 
                             Source=akutan;
                    </DEFAULT>
                    <READONLY>1</READONLY>
                </PROPERTYCONSTRAINT>
            </PROPERTYCONSTRAINTS> 
        </CONSTRAINTS>
    </ELEMENT>
    
  3. Save your changes to MyPolicy.tdl.
  4. Reopen the application to observe its new functionality.
    1. Open MyTemplate. In Solution Explorer, expand the WinApp project and double-click Form1.cs to open it in the designer.
    2. Drag the OleDbConnection item from the Toolbox onto the form. Select the OleDbConnection object and examine the ConnectionString property in the Properties window. Note that it has the value specified above and is now read-only.
  5. Select the File menu and click Save All to save your changes and close the solution.

Scenario Six: Specifying UI standards

This scenario for applying constraints deals with imposing user-interface standards. For example, suppose you want all Windows controls to use a Tahoma, 12pt font. You could place a constraint on every individual Toolbox item, but that would be cumbersome and difficult to maintain. Instead, you can leverage the knowledge that all controls derive from a common base class, System.Windows.Forms.Control, to set a property constraint for all Windows Forms controls.

To set a constraint on a common base class

  1. Define a new ELEMENT in MyPolicy.tdl as a container for a new constraint by adding the following ELEMENT definition to the policy file:
    <ELEMENT>
        <ID>codeWinFormsControl</ID>
            <IDENTIFIERS>
                <IDENTIFIER>
                    <TYPE>CODEVARIABLE</TYPE>
                    <IDENTIFIERDATA>
                        <NAME>TYPEINHERITS</NAME>
                        <VALUE>System.Windows.Forms.Control</VALUE>
                    </IDENTIFIERDATA>
                </IDENTIFIER>
            </IDENTIFIERS>
    </ELEMENT>
    
  2. Add a CONSTRAINTS node to that ELEMENT definition, as shown in bold below:
    <ELEMENT>
        <ID>codeWinFormsControl</ID>
        <IDENTIFIERS>
            <IDENTIFIER>
                <TYPE>CODEVARIABLE</TYPE>
                <IDENTIFIERDATA>
                    <NAME>TYPEINHERITS</NAME>
                    <VALUE>System.Windows.Forms.Control</VALUE>
                </IDENTIFIERDATA>
            </IDENTIFIER>
        </IDENTIFIERS>
        <CONSTRAINTS>
            <PROPERTYCONSTRAINTS>
                <PROPERTYCONSTRAINT>
                    <NAME>Font</NAME>
                    <DEFAULT>Tahoma, 12pt</DEFAULT>
                    <READONLY>1</READONLY>
                </PROPERTYCONSTRAINT>
            </PROPERTYCONSTRAINTS> 
        </CONSTRAINTS>
    </ELEMENT>
    
  3. Save the changes to the policy file.
  4. Reopen the MyTemplate solution.
  5. Open Form1.cs in the designer and drag any controls onto the form. Note that they all have a font set to "Tahoma, 12pt".
  6. Delete the added controls and save the application.
  7. Close the solution.

This approach has one drawback. In Visual Studio .NET, policy does not support the notion of "more specific" identification becoming the default when there is a conflict. If you modify the goal to apply Tahoma, 12pt to all controls except Buttons, which get Times New Roman, 14pt, you would have a problem. If you attempt to just add the extra constraint to codeWinFormsButton, you receive a policy reminder indicating that you have conflicting constraints. To accomplish the goal, you can use the approach employed for Menu and Toolbox constraints. You can specify a default constraint and then override it for codeWinFormsButton.

To set a default constraint and then override it

  1. Edit MyPolicy.tdl, deleting the ELEMENT definition for codeWinFormsControl.
  2. Edit the DEFAULTSETTINGS node to match the following:
    <CONSTRAINTS>
    <!-- you can leave the old menu and Toolbox constraints here -->
        <PROPERTYCONSTRAINTS>
            <PROPERTYCONSTRAINT>
                <NAME>Font</NAME>
                <DEFAULT>Tahoma, 12pt</DEFAULT>
                <READONLY>1</READONLY>
            </PROPERTYCONSTRAINT>
        </PROPERTYCONSTRAINTS> 
    </CONSTRAINTS>
    
  3. Modify the definition for the codeWinFormsButton ELEMENT to include the following PROPERTYCONSTRAINTS node, shown in bold:
    <ELEMENT>
        <ID>codeWinFormsButton</ID>
        <IDENTIFIERS>
            <IDENTIFIER>
                <TYPE>CODEVARIABLE</TYPE>
                <IDENTIFIERDATA>
                    <NAME>TYPENAME</NAME>
                    <VALUE>System.Windows.Forms.Button</VALUE>
                </IDENTIFIERDATA>
            </IDENTIFIER>
        </IDENTIFIERS>
        <CONSTRAINTS>
            <PROPERTYCONSTRAINTS>
                <PROPERTYCONSTRAINT>
                    <NAME>Font</NAME>
                    <DEFAULT>Times New Roman, 14pt</DEFAULT>
                    <READONLY>1</READONLY>
                </PROPERTYCONSTRAINT>
            </PROPERTYCONSTRAINTS> 
        </CONSTRAINTS>
        <FEATURELINKS>
            <TOOLBOXLINKS>
                <TOOLBOXLINK>tboxWinFormsButton</TOOLBOXLINK>
            </TOOLBOXLINKS>
        </FEATURELINKS>
    </ELEMENT>
    
  4. Save your changes and reopen the application.
  5. Open Form1.cs in the designer.
  6. Drag a few controls, including a button, onto the form. Note that button has a different font.

You have successfully overridden the default property constraint with an ELEMENT constraint.

You typically use the two narrowest scopes (ELEMENTSET constraints and Member constraints) only where a component or control is used with different parent ELEMENT nodes. For components (such as the data access component, and the components Toolbox items) and controls, that parent ELEMENT is the form, Web Form, or Web page on which they reside. The narrowest scopes are also useful in cases where an application contains custom forms and you want to apply different constraints on the items on different types of forms.

For example, you can place one restriction on a MessageQueue component when it is used with a Web Form and a different restriction when it is used with a Windows Form. This is necessary, for example, if the timeout should be longer for the Web Form than for the Windows Form. To place these restrictions, first modify the policy for UIProjects.etp, allowing Web Applications to be added.

To place restrictions on a MessageQueue component when it is used on a Web Form or a Windows Form

  1. Edit MyPolicy.tdl, updating the ELEMENTSET definition for etpUIProjects to include projCSharpWebApp as indicated below in bold:
    <ELEMENTSET>
        <DEFAULTACTION>EXCLUDE</DEFAULTACTION>
        <ORDER>INCLUDEEXCLUDE</ORDER>
        <INCLUDE>projWinApp</INCLUDE>
        <INCLUDE>projCSharpWebApp</INCLUDE>
        <INCLUDE>projCSharpWinApp</INCLUDE>
        <INCLUDE>projCSharpEmptyProject</INCLUDE>
    </ELEMENTSET>
    
  2. Insert the following ELEMENTSET definition for codeWinForm:
    <ELEMENTSET>
        <DEFAULTACTION>INCLUDE</DEFAULTACTION>
        <CONSTRAINTS>
            <PROPERTYCONSTRAINTS>
                <PROPERTYCONSTRAINT>
                    <NAME>DefaultPropertiesToSend.TimeToBeReceived</NAME>
                    <READONLY>0</READONLY>
                    <MINVALUE>10</MINVALUE>
                    <MAXVALUE>30</MAXVALUE>
                </PROPERTYCONSTRAINT>
            </PROPERTYCONSTRAINTS> 
        </CONSTRAINTS>
    </ELEMENTSET>
    
  3. Insert the following ELEMENTSET definition for codeWebForm:
    <ELEMENTSET>
        <DEFAULTACTION>INCLUDE</DEFAULTACTION>
        <CONSTRAINTS>
            <PROPERTYCONSTRAINTS>
                <PROPERTYCONSTRAINT>
                    <NAME>DefaultPropertiesToSend.TimeToBeReceived</NAME>
                    <READONLY>0</READONLY>
                    <MINVALUE>30</MINVALUE>
                    <MAXVALUE>60</MAXVALUE>
                </PROPERTYCONSTRAINT>
            </PROPERTYCONSTRAINTS> 
        </CONSTRAINTS>
    </ELEMENTSET>
    
  4. Save your changes to the policy file.
  5. Reopen the MyTemplate solution.
  6. In Solution Explorer, right-click UIProjects, point to Add, and click New Project. Select C# Projects in the Project Types pane, and select ASP.NET Web Application on the right. Give the new project the name WebApp1 and click OK.
  7. In Solution Explorer, select WebForm1.aspx beneath the WebApp1 node. Notice that it identifies as "projItemWebForm, codeHTMLBody" in the Properties window. The corresponding form is open in the designer. From the Component tab of the Toolbox, drag a MessageQueue component onto the Web Form. You immediately see a policy reminder in the Task List informing you that the default DefaultPropertiesToSend.TimeToBeReceived is outside the policy-specified range of 30 to 60 for this component when used on a Web Form.
  8. In Solution Explorer, expand the WinApp node and open Form1.cs in the designer. From the Component tab of the Toolbox, drag a MessageQueue component onto the Windows Form. Select the MessageQueue component and, in the Properties window, try to enter a value for TimeToBeReceived outside the range of 10 to 30. You immediately see a policy reminder in the Task List informing you that the default DefaultPropertiesToSend.TimeToBeReceived is outside the policy-specified range of 10 to 30 for this component when used on a Windows Form.
  9. On the File menu, click Save All to save your changes and close the solution.

The approach of placing restrictions on the ELEMENTSET has a disadvantage in that all child ELEMENT nodes that support the named property apply the constraint. To ensure this constraint is applied only to a MessageQueue component when it is placed on a Windows Form or Web Form, you need to make one final set of changes to your policy file. Change the constraints from ELEMENTSET constraints to MEMBERCONSTRAINTS, specifying a specific ELEMENT within the ELEMENTSET to which you want the constraints to be applied.

To ensure that this constraint is applied only to a MessageQueue component when it is placed on a Windows Form or Web Form

  1. Edit MyPolicy.tdl, changing the ELEMENTSET definition for codeWinForm to match the following:
    <ELEMENTSET>
        <DEFAULTACTION>INCLUDE</DEFAULTACTION>
        <MEMBERCONSTRAINTS>
            <MEMBERCONSTRAINT>
                <ID>codeComponentsMessageQueue</ID>
                <PROPERTYCONSTRAINTS>
                    <PROPERTYCONSTRAINT>
                        <NAME>DefaultPropertiesToSend.TimeToBeReceived</NAME>
                        <READONLY>0</READONLY>
                        <MINVALUE>10</MINVALUE>
                        <MAXVALUE>30</MAXVALUE>
                    </PROPERTYCONSTRAINT>
                </PROPERTYCONSTRAINTS> 
            </MEMBERCONSTRAINT>
        </MEMBERCONSTRAINTS>
    </ELEMENTSET>
    
  2. Change the ELEMENTSET definition for codeWebForm to match the following:
    <ELEMENTSET>
        <DEFAULTACTION>INCLUDE</DEFAULTACTION>
        <MEMBERCONSTRAINTS>
            <MEMBERCONSTRAINT>
                <ID>codeComponentsMessageQueue</ID>
                <PROPERTYCONSTRAINTS>
                    <PROPERTYCONSTRAINT>
                        <NAME>DefaultPropertiesToSend.TimeToBeReceived</NAME>   
                        <READONLY>0</READONLY>
                        <MINVALUE>30</MINVALUE>
                        <MAXVALUE>60</MAXVALUE>
                    </PROPERTYCONSTRAINT>
                </PROPERTYCONSTRAINTS> 
            </MEMBERCONSTRAINT>
        </MEMBERCONSTRAINTS>
    </ELEMENTSET>
    
  3. Save your changes.
  4. Reopen the MyTemplate solution.
  5. Check the constraints on the MessageQueue components to see that they are both still applied.
  6. Close your solution.

See Also

Defining Constraints in TDL | Defining ELEMENTSET Constraints | Constraint Scoping Levels | ELEMENT | ELEMENTSET | MENULINK | TOOLBOXLINK | MENUCONSTRAINT | TOOLBOXCONSTRAINT | PROPERTYCONSTRAINT | DEFAULTSETTINGS

Show:
© 2015 Microsoft