Design Principles
| 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. |
This section contains design principles that you can use to develop Guidance Packages with the Guidance Automation Toolkit. In addition to general guidelines, it contains specific information about designing Visual Studio templates and bound and unbound recipes.
When designing Guidance Packages, you should bear in mind that they are unique to the solution, user, and computer on which they are installed and enabled. To allow your Guidance Packages to be used in a multi-developer environment, you should avoid complex Guidance Packages that execute many recipes, because these packages could often contain invalid references. For example, a developer could enable a Guidance Package, unfold a template that attaches a recipe reference to a new project, close the solution, and check the solution into a Source Control System (SCS). Another developer could then synchronize with the SCS, rename the same project, and check in the solution. In this case, the first developer would have a disconnected recipe reference the next time he or she synchronizes with the SCS and opens the solution.
By designing your Guidance Packages to perform a specific task or small set of tasks, you can ensure that they are easier to create, test, and use as required. Such Guidance Packages will often be enabled, used, and disabled, all within a single development session, avoiding the problems of multiple developers working on the same solution.
See also
When to Use Templates | When to Use Bound and Unbound Recipes