Designing Recipes
| Retired Content |
|---|
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. |
Recipes can be bound and non-recurring, bound and recurring, or unbound (which are, by definition, recurring). As you design your Guidance Packages, it is important to understand when to use each type of recipe reference. You should also understand when you should use spawning recipes.
Bound Non-Recurring Recipes
After it executes, a bound non-recurring recipe reference is removed. You should use bound, non-recurring recipe references when:
- The task supported by the recipe is relevant only to a specific instance of solution element (item, project or folder).
- Deleting the element means that the guidance associated with the element should also be deleted.
- The task automated by the recipe should be performed only once.
Bound Recurring Recipes
A bound recurring recipe reference remains associated with a solution element after it executes. It can only be removed using Guidance Package Manager. You should use bound recurring recipe references when:
- The recurring task is relevant only to the element to which the recipe is attached
- The task supported by the recipe can be repeated multiple times on the body of its element (for example, when your solution is designed to contain all messages, schemas, and classes in one project, and you design a recurring recipe to create a message class, and attach it to the project).
Unbound Recipes
Unbound recipe references are not invalidated when solution elements change their name or are deleted. As such, they are more resilient than bound references. You should use unbound recipe references when:
- The recipe reference applies to more than one instance of a solution element (for example all C# projects).
- You need more granular control over when a recipe should apply to a specific element.
- You need to write common utilities that may apply to a variety of solution elements.
Note
Because unbound references behave like recurring references, a recurring, bound recipe reference can always be replaced with an unbound reference. For example, instead of attaching a recurring reference to C# project A, you can write an unbound reference that will only apply to (p.kind == C# and p.name == "A").
Spawning Recipes
You can use recipe spawning to break a task into subtasks that are easier to handle. You should use them to break a large recipe into a set of smaller recipes, so that the first recipe does the preliminary work and is followed by a number of child recipes. This avoids the need to write large, complex recipes with many arguments and actions.
You should not use recipe spawning to guide your developers through specific development paths.