Overview of Domain-Specific Language Tools
By using Domain-Specific Language Tools, you can design graphical languages and generate code and other text output from the domain-specific languages.
Domain-Specific Language Tools consists of:
A project wizard that creates a fully configured solution. In this solution, you can define a domain model that consists of a designer and a text output generator. If you run a completed solution from inside Visual Studio, a test solution opens in a separate instance of Visual Studio so that you can test the designer and the text output generator.
A graphical designer for defining and editing domain models.
Designer definitions in XML. The code for implementing designers is generated from these definitions so that you can define a graphical designer hosted in Visual Studio without manually writing any code.
A set of code generators, which take a domain model definition and a designer definition as input and produce code that implements both of the components as output. The code generators also validate the domain model and the designer definition, and they raise errors and warnings accordingly.
A framework for defining text output generators. These template-based generators take data (models) that use a domain model as input and generate text output that is based on the template. Parameters in the template are substituted by using the results of running a Visual C# script that is embedded in the template.
The following illustration provides a high-level overview of how you design, customize, test, and deploy a domain-specific language.
Domain-Specific Language Process
.png)
To design a language, you begin by using the Domain-Specific Language Designer Wizard. For your convenience, the wizard provides the following solution templates:
Task Flow
Class Diagrams
Minimal Language
Component Models
Canonical Sample
For more information, see Choosing a Domain-Specific Language Solution Template.
As you complete the wizard, you specify the features of your domain-specific language solution. For more information, see How to: Create Domain-Specific Language Solutions.
As a result of running the wizard, a Visual Studio solution is created for you. The solution contains the following projects:
Dsl
The Dsl project defines the domain-specific language and its editing and processing tools.
DslPackage
The DslPackage project determines how the language tools integrate with Visual Studio.
You can either use the template language as it is, or you can modify it to suit your own needs. Nearly all of the code in the solution is generated from the language definition files, currently in DomainModel.tt. Therefore, you make most changes to the language by modifying this file.
Code is generated from text templates (typically called *.tt), which read the language definition and output the appropriate code. Therefore, whenever you modify the language definition files, you should transform all templates. For more information, see How to: Run Text Templates and How to: Generate Code from Text Templates.
You can also provide additional code to refine the behavior of the model designer and to define constraints over your language. If required, you can make significant changes by modifying the text templates.
To test the domain-specific language, you build and open the solution in an instance of the Visual Studioexperimental build with a debugging project. You can then use the debugging project to test your domain-specific language. In many cases, you create code or other artifacts from your domain-specific language. You can build text templates in the debugging project, which read the model and generate files from it. After you verify that everything works correctly, you can create a deployment package (.msi file) to distribute your domain-specific language.
See Also
Concepts
Creating Domain-Specific Languages
Generating Artifacts Using Text Templates