This document describes known issues with the version 1 release of Domain Specific Language Tools.
Known issues are grouped by categories, one category per section.
The Dsl project contains the DslDefinition.dsl file, which contains the definition of your domain-specific language. By default, DslDefinition.dsl is edited with the Domain-Specific Language Designer.
| 113353 | Second successive File/Save on .dsl file with changed .diagram file causes unexpected overwriting popup |
| Repro: | - Make sure that Team Foundation Server is your active source control provider.
Expected result: The file is saved a second time
Actual result: A Conflicting modifications detected dialog box appears. The text reads "The file dsldefition.dsl.diagram has been changed since you opened it. Would you like to save the version you have over the changes on disk?" and the command buttons include "Save as..." "Overwrite" "Discard in-memory changes" "Cancel" "Help". - Open a .dsl file in the editor.
- Modify the expand/collapse of a node.
- Press Ctrl-S to save the file
- Press Ctrl-S to save the file again
|
| Workaround: | Overwrite the file. |
| 114899 | Can not recreate decorator property paths in DSL Details window |
| | This issue arises only if you have manually edited the XML file. This situation can not occur if you edit files only with the Dsl Designer. |
| Repro: | - Create a new DSL with at least one decorator map.
Expected result: You can define a property path.
Actual result: The user interface for defining a property path is disabled. - Open the .dsl file in the XML editor.
- Modify the decorator map definition so that the PropertyPath is missing, as shown:
<DecoratorMap>
<TextDecoratorMoniker Name="MultipleAssociationRoleConnector/TargetMultiplicity" />
<PropertyDisplayed>
</PropertyDisplayed>
</DecoratorMap>
- Select the shape map and go to the Decorators tab in the Mapping Details window.
|
| Workaround: | Select and clear the mapping check box in the decorators list view, and the property path will be recreated. |
| 117186 | Property grid references to classes cannot disambiguate between identically named classes in different namespaces |
| Repro: | Create a model that contains two domain classes that have the same name in different namespaces. In the DSL Explorer, try to work out which is which, in contexts that refer to classes and do not appear on the diagram: XmlClassData, Editor, Tools.
Expected result: You can clearly distinguish between the classes.
Actual result: You can not distinguish between them. |
| Workaround: | Temporarily rename one of the classes, or do not use classes with the same name in different namespaces. |
| 118095 | Selection in DSL Explorer is not saved on window focus change. |
| Repro: | Open a .dsl file, expand the tree in the DSL Explorer and select a node. After that, switch the window to a code editor and switch back to DslDesigner. The tree in DSL Explorer gets collapsed again and the selection is lost. The selection should be saved when the focus changes. |
| Workaround: | None. |
| 119854 | Moving selection out of a DSL Details field loses your edits |
| Repro: | Select a merge directive in the DSL Explorer. In the DSL Details window, edit a LinkPath. Select something else in the DSL Explorer. Move the selection back to the original element.
Expected result: Field re-appears as edited.
Actual result: Field is unchanged since before your edit. |
| Workaround: | Always press ENTER when you finish editing. |
| 119955 | Inheritance line arrow is not drawn at the correct location when multiple inheritance lines overlap |
| | This error is intermittent. For example, if you have three domain classes B, C and D deriving from A, two of the arrows will overlap. If you create three domain classes and then delete one of them, the remaining two lines will overlap as expected. |
| Repro: | Create three domain classes, A, B and C, with B and C deriving from A. Notice that the arrows of the two inheritance lines don't overlap. |
| Workaround: | None. |
| 121110 | Double-clicking doesn't navigate to the new domain class when adding from the toolbox in the same way that dragging does |
| Repro: | Create a language using the class diagram template. Double-click the domain class tool in the toolbox to add a domain class to the diagram.
Expected result: The new domain class should be visible and selected.
Actual result: The new domain class is created in a region of the diagram that is not in view, so the user does not have any feedback that the class was created. |
| Workaround: | Drag the tool onto the diagram instead. |
| 121685 | Changing the editor's file extension does not alter names of files that are used to build project templates |
| Repro: | Create a language. Change its file extension in the editor properties, for example from abc to efg, and re-apply the text templates.
Expected result: The files abc.diagram and abc.abc in the ProjectItemTemplates folder of the DslPackage project are renamed as efg.diagram and efg.efg.
Actual result: The files are not renamed, which causes a build error. |
| Workaround: | Rename the files manually. |
| 121698 | Creating two embeddings between the same pair of classes creates invalid ElementMergeDirectives |
| Repro: | Create a language using the minimal language template. Drag a second embedding between ExampleModel and ExampleElements. Make the second embedding a subclass of the first.
Expected result: No validation errors are reported.
Actual result: Various validation errors are reported including ones about duplicate properties, and another about duplicate merge directives. |
| Workaround: | Change the property names of roles to remove the validation errors about duplicate properties. Remove one of the duplicate merge directives through the DSL Explorer. You might need to write custom code for the remaining merge directive to distinguish between the two cases (that is, to determine when to create a link of each relationship on merge and when not to). |
| 124818 | Inheritance arrows for inheritance do not always line up properly |
| | The repro steps for this issue involve geometry shapes, but it has been seen with other kinds of element. |
| Repro: | Create a base geometry shape named BaseShape. Create a geometry shape named Thing1Shape. Make Thing1Shape inherit from BaseShape. Run "bring tree here" command to get the definition of Thing1Shape under BaseShape. Create another geometry shape named Thing2Shape. Make Thing2Shape inherit from BaseShape. Look at the inheritance arrows.
Expected result: The arrows merge.
Actual result: The arrow for Thing1Shape gets rotated 90 degrees counter clockwise, and the lines do not converge. |
| Workaround: | Expanding or collapsing some element, forcing the diagram to redraw, sometimes fixes the problem. |
| 124949 | Clicking on a +/- button to collapse relationship tree of a class sometimes does not seem to work |
| | The reason for the bug is that the relationship connector's mouse sensitive area overlaps with the mouse sensitive area of the collapse button and the connector has a higher Z-Order. |
| Repro: | - Create a new language using the class diagram template
Expected result: The relationship subtree should collapse.
Actual result: The relationship subtree does not collapse. The relationship connector gets the focus instead. - Open the .dsl file for the language that you just created
- Find the ModelClass domain class (under ModelType domain class)
- Find the "-" button on the bottom edge of the ModelClass shape
- Point at the "-" button
- The button is highlighted when you point at the top half of the button but not if you point at the bottom half of the button.
- Click teh bottom half of the button.
|
| Workaround: | Right-click the shape and choose Collapse Relationships Tree. |
| 125688 | Icon picker dialog box does not intrepret directory names that end in a backslash (\) correctly and interprets directory names without a backslash as file names |
| Repro: | - Create a language using the minimal language template
Expected result: You should be browsing in the system32 directory
Actual result: If you did not type the trailing backslash then you will be browsing in the windows directory looking for a file named system32. If you did type the backslash then an error message appears, saying that d:\windows\system32\ is an invalid filename. - Open the .dsl file, and in the DSL Explorer click on the editor node and then click the builder button on icon property to launch picker dialog
- Type d:\windows\system32 or d:\windows\system32\ in the File name box and press ... button to browse
|
| Workaround: | Do not type anything in the File name box before browsing. |
| 130617 | The Split Tree command messes up the diagram |
| Repro: | - Create a language using the minimal language template.
Expected result: The diagram redraws correctly.
Actual result: Lines go through ExampleElement and text overlaps. - Add another relationship to ExampleElement.
- Call SplitTree on ExampleElement.
|
| Workaround: | Force the diagram to be redrawn (for example, by expanding or collapsing some element). |
| 117495 | Format specifier '{0}' appears in validation error. |
| Repro: | - Create a new language.
Expected result: One validation message without the format specifier '{0}'
Actual result: Duplicate validation message that contains'{0}':
Error 1 Editor {0} has no RootClass.
Error 2 Invalid file extension "" defined in editor for DSL Language93.
Error 3 Editor has no RootClass - Open the .dsl file, and delete the "Editor" node in the DSL Explorer.
- Right-click the root node in the DSL Explorer and click Add Custom Editor.
- Save the .dsl file.
|
| Workaround: | None. |
| | |
Using a designer generated from a DSL DefinitionThese issues arise when a domain-specific language has been defined and you are creating, editing, and using models (that is, instances of the domain-specific language). Models are stored in pairs of files. These files include the main concepts file, in which the class-instances and the relationship-instances are stored, and the subsidiary .diagram file, in which layout information is kept. In the Solution Explorer, the .diagram file might be hidden underneath the main file. Click the [+] to display it. Typically, any tools and templates that you create will read the class and relationship information. Therefore, you can delete the diagram file in case of any problem, but you will need to rearrange the layout. The files are designed to be readable and easy to process with XML tools. |
| The diagram file gets out of synchronization with the model file. |
| | Every model is stored in two files. The main model file has the conceptual information, and the subsidiary .diagram file has the visual layout. When the definition of the domain-specific language is changed can become desynchronized. |
| Workaround: | Delete the .diagram file, and reopen. A new diagram will be created which you will then need to manually relayout. |
| Models do not load after a change to the DSL definition. |
| | The definition of a new domain-specific language is likely to change frequently, especially during the development of that language. When a domain-specific language is changed, you do not want to lose all the models (instance files of the domain-specific language) that were generated in the older version of the domain-specific language. In general, when a user's model is read, the deserializer is 'forgiving': It ignores elements that do not conform to the DSL Definition, and it fills in default values for elements that are missing. In extreme cases of domain-specific language change, these adjustements are not sufficient and the model files must be edited or transformed before they can be read in. |
| Workaround: | Try opening a file and examine the errors that appear so that you can identify what needs to change. Knowledge of the changes made in the DSL definition will be a helpful guide. Make the changes manually on a small file until you can load it. Consider automating those changes, for example by writing some XSLT, especially if you have a large number of existing files to transform. Alternatively, consider whether the change in the DSL definition is really required or if a less drastic change might of achieve a similar effect. |
| Package load failures on running Debugging solution |
| | This error usually indicates that a package (such as a previous domain-specific language that you were experimenting with) still has a registry entry but its assembly has been deleted. |
| Workaround: | Reset the experimental registry hive for the Visual Studio SDK. Close all instances of Visual Studio. On the Start menu, point to Visual Studio SDK, and follow the nested menus to Reset the Visual Studio 2005 Experimental Hive. You will need to rebuild any domain-specific languages that you were using in the experimental hive. |
| 98674 | Performing a get latest version operation on a project that has an uncommitted model file should remove the model file and close it |
| Repro: | - Create a deployable dsomain-specific designer and deploy it.
Expected result: Because the addition of the model file is not a committed change, the Get Latest Version operation should remove the model from the project and close it since it is not part of the solution. Actual result: The model file is removed but not closed. - Create a C# class library and add it to source control.
- Make sure the class library project is checked in.
- Add a new model for the designer deployed in step 1 to the project, but do not check it in.
- Right click the project and choose Get Latest Version.
- When prompted, choose to overwrite the project.
|
| Workaround: | Close the model file manually. |
| 109085 | Port Connectors do not have correct boundaries on generated designer |
| Repro: | - Run a designer based on the component model template and drop two shapes on it.
Expected result: The cursor should change shape because it is on the Port.
Actual result: The cursor remtains its shape as if the mouse is still pointing to the connector itself. - Drop two ports (out and in) on the shapes and connect the two ports using a connector.
- Select the connector and point to where the connector ends on the consumer port.
|
| Workaround: | None. |
| 118601 | Using Auto-incrementing version numbers can cause a generated Setup project to create an invalid MSI package |
| | Including an assembly attribute such as "[assembly: AssemblyVersion(@"1.0.*")]" in either the Dsl or DslPackage assemblies can lead to a generated MSI that will not correctly install the target designer. The MSI will build and install without errors. However, a package load failure will then occur when Visual Studio is launched. This failure occurs because some of the generated .wxs files (Main.tt and Registry.tt) refer to the full assembly name of the target .dll files, including the version numbers. Building the Setup project will cause the Dsl and DslPackage assemblies to rebuild, possibly changing their version numbers. However, the text templates in the Setup project are not automatically re-run before the Setup project is built, so the assembly version numbers will not be incremented. |
| Workaround: | Rerun the text templates in the solution manually before you rebuild the setup project. |
| 118635 | Text decorators in headers of horizontal swimlanes need to be rotated through 90 degrees |
| Repro: | In a language that defines swimlanes (for example, one that is derived from the task flow template), set the alignment property to Horizontal. Build and run the designer.
Expected result: The text in the header of the swimlane is aligned vertically along the left edge of the swimlane.
Actual result: The text is aligned horizontally in the top-left corner of the swimlane. |
| Workaround: | The issue is probably in the Shapes.tt code generation template. You might be able to fix the problem yourself by overwriting that template with a copy of the text in the included file referred to by within the template and then making the appropriate change to the copied text. |
| 119522 | Ports do not appear in the correct location in generated designer |
| Repro: | Run a designer based on the ComponentModel template. Create a component shape and resize it to the smallest possible size. Double-click the OutputPort/InputPort item in the toolbox to automatically place the port on the Component shape. Expected result: The port appears on the edge of the component Shape.
Actual result: The port appears next to the edge of the component shape and comes back on the edge when the shape is resized. |
| Workaround: | Don't set the default size for a shape that uses ports to be too small. Write custom code to prevent the shape being resized too small. |
| 124853 | Line routing for connectors between ports jumps from edge of port to middle of port |
| Repro: | Run a designer based on the component model template. Open the Sample model. Move Component1 slightly to the right. Move the port on the right of Component1 to the left of the component. Reposition the leftmost vertical section of the connector.
Expected result: The connector remains connected to the edge of the ports.
Actual result: The connector jumps to be connected to the middle of the ports. |
| Workaround: | None. |
| 130478 | Connectors do not reroute and behave badly in the Component Model designer |
| Repro: | Run the target designer for Component Models. Draw a connection between two ports. Right-click the connection and choose Reroute.
Expected result: The connector reroutes and shows new position.
Actual result: The connector disappears from the diagram. When the diagram refreshes the connector appears again. |
| Workaround: | None. |
You are welcome to join the discussions and ask questions on the Domain-Specific Language Tools Forum. This resource is invaluable for swapping tips and techniques and for gettting the most recent news about the Domain-Specific Language Tools.