You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/framework/wcf/contract-first-tool.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -55,11 +55,11 @@ Service contracts often need to be created from existing services. In [!INCLUDE[
55
55
## Configuring contract-first options
56
56
Contract-first options can be configured in the Properties menu of a WCF project. To enable contract-first development, select the **Enable XSD as Type Definition Language** check box in the WCF page of the project properties window.
The following advanced settings can be configured for code generation from contracts. Settings can only be configured for all of the files in the project; settings cannot be configured for individual files at this time.
65
65
@@ -112,9 +112,9 @@ Service contracts often need to be created from existing services. In [!INCLUDE[
112
112
using MyProjectNamespace.ContractTypes;
113
113
```
114
114
115
-
The types defined in the service contract will then be resolvable in the project, as shown below.
115
+
The types defined in the service contract will then be resolvable in the project, as shown below:
116
116
117
-
![Using types derived from a service contract](../../../docs/framework/wcf/media/contractfirsttypes.png"ContractFirstTypes")
117
+
118
118
119
119
The types generated by the tool are created in the GeneratedXSDTypes.cs file. The file is created in the \<project directory>/obj/\<build configuration>/XSDGeneratedCode/ directory by default. The sample schema at the beginning of this topic is converted as follows:
31
29
32
30
> [!IMPORTANT]
33
31
> The samples may already be installed on your machine. Check for the following (default) directory before continuing.
@@ -40,19 +38,15 @@ Figure 1: Sample Overview
40
38
41
39
## RuleSet Tool
42
40
43
-
A screen shot of the RuleSet tool is shown in Figure 2. From the **Rule Store** menu, you can load the available RuleSets from the database and save modified RuleSets back to the store. An application configuration file provides a database connection string for the RuleSet database. When you start the tool, it automatically loads the RuleSets from the configured database.
The following image is a screenshot of the RuleSet tool. From the **Rule Store** menu, you can load the available RuleSets from the database and save modified RuleSets back to the store. An application configuration file provides a database connection string for the RuleSet database. When you start the tool, it automatically loads the RuleSets from the configured database.
46
42
47
-
Figure 2: RuleSet Browser
43
+
48
44
49
45
The RuleSet tool applies major and minor version numbers to the RuleSets, allowing you to simultaneously maintain and store multiple versions (the tool provides no locking or other configuration management features in addition to the versioning capability). Using the tool, you can create new RuleSet versions or delete existing versions. When you click **New**, the tool creates a new RuleSet name and applies version 1.0. When you copy a version, the tool creates a copy of the selected RuleSet version, including the contained rules, and assigns new, unique version numbers. These version numbers are based on the version numbers of existing RuleSets. You can change the RuleSet name and version numbers using the associated fields on the form.
50
46
51
-
When you click **Edit Rules**, the RuleSet editor starts, as shown in Figure 3.
When you click **Edit Rules**, the RuleSet editor starts, as shown in the following image:
54
48
55
-
Figure 3: RuleSet Editor
49
+
56
50
57
51
This is a re-hosting of the editor dialog that is part of the Windows Workflow Foundation Visual Studio add-in. It provides the same functionality, including Intellisense support. The rules are authored against a target type (such as a workflow) that is associated with the RuleSet in the tool; when you click **Browse** in the main tool dialog, the **Workflow/Type Selector** dialog appears, as shown in Figure 4.
58
52
@@ -64,21 +58,17 @@ You can use the **Workflow/Type Selector** dialog to specify an assembly and a s
64
58
65
59
The path to the assembly file and the type `name are stored with the` RuleSet in the database, so that when the RuleSet is retrieved from the database, the tool attempts to automatically load the target type.
66
60
67
-
When you click **OK** in the **Workflow/Type Selector** dialog, it validates the selected type against the RuleSet, to ensure that the target type has all the members referenced by the rules. Errors are shown in a **Validation Errors** dialog (see Figure 5). You can choose to continue with the change despite the errors, or click **Cancel**. From the **Tools** menu in the main tool dialog, you can click **Validate** to re-validate the RuleSet version against the target activity.
61
+
When you click **OK** in the **Workflow/Type Selector** dialog, it validates the selected type against the RuleSet, to ensure that the target type has all the members referenced by the rules. Errors are shown in a **Validation Errors** dialog. You can choose to continue with the change despite the errors, or click **Cancel**. From the **Tools** menu in the main tool dialog, you can click **Validate** to re-validate the RuleSet version against the target activity.
68
62
69
-
![Validation Errors from External RuleSet Sample](./media/validationerrorsruleset.png"ValidationErrorsRuleSet")
70
-
71
-
Figure 5: Validation Errors
63
+
72
64
73
65
From the **Data** menu in the tool, you can import and export RuleSets. When you click **Import**, a file-chooser dialog appears, from which you can select a .rules file. This may or may not be a file initially created in Visual Studio. The .rules file should contain a serialized `RuleDefinitions` instance that contains a collection of conditions and a collection of RuleSets. The tool does not use the conditions collection, but it does use the `RuleDefinitions` .rules format to allow interaction with the Visual Studio environment.
74
66
75
-
After selecting a .rules file, a **RuleSet Selector** dialog appears (see Figure 6). You can use the dialog to select the RuleSets from the file that you want to import (the default specifies all RuleSets). RuleSets in the .rules file do not have version numbers, because their versioning within a WF project is the same as the version of the assembly. During the importing process, the tool automatically assigns the next available major version number (which you can change after importing); you can see the assigned version numbers in the **RuleSet Selector** list.
76
-
77
-
For each RuleSet it imports, the tool attempts to locate the associated type from the bin\Debug folder under the location of the .rules file (if it exists), based on the members used in the RuleSet. If the tool finds multiple matching types, it attempts to choose a type based on a match between the .rules file name and the type name (for example, the `Workflow1` type corresponds to Workflow1.rules). If multiple matches exist, you are prompted to select the type. If this auto-identification mechanism fails to locate a matching assembly or type, then after importing you can click **Browse** on the main tool dialog to navigate to the associated type.
67
+
After selecting a .rules file, a **RuleSet Selector** dialog appears. You can use the dialog to select the RuleSets from the file that you want to import (the default specifies all RuleSets). RuleSets in the .rules file do not have version numbers, because their versioning within a WF project is the same as the version of the assembly. During the importing process, the tool automatically assigns the next available major version number (which you can change after importing); you can see the assigned version numbers in the **RuleSet Selector** list.
For each RuleSet it imports, the tool attempts to locate the associated type from the bin\Debug folder under the location of the .rules file (if it exists), based on the members used in the RuleSet. If the tool finds multiple matching types, it attempts to choose a type based on a match between the .rules file name and the type name (for example, the `Workflow1` type corresponds to Workflow1.rules). If multiple matches exist, you are prompted to select the type. If this auto-identification mechanism fails to locate a matching assembly or type, then after importing you can click **Browse** on the main tool dialog to navigate to the associated type. The following image shows the RuleSet Selector:
80
70
81
-
Figure 6: RuleSet Selector
71
+
82
72
83
73
When you click **Data-Export** from the main tool menu, the **RuleSet Selector** dialog appears again, from which you can determine the RuleSets from the database that should be exported. When you click **OK**, a **Save File** dialog appears, in which you can specify the name and location of the resulting .rules file. Because the .rules file does not contain version information, you can only select one RuleSet version with a given RuleSet name.
0 commit comments