Note: installing this software requires uninstalling the previously installed versions of this software.

I has been reported that, in rare cases, some migrated DSL projects may exhibit the following issue: the DSL package project does not compile due to an error in the DslPackage\GeneratedCode\Package.cs file caused by an undeclared namespace alias

There is an easy workaround:

• open the file DslPackage\GeneratedCode\DslPackage.tt
• replace the single occurrence of the text string "VSTextTemplatingHost::" with "global::Microsoft.VisualStudio.TextTemplating.VSHost."
• run the custom tool to regenerate the Package.cs file.

The project will then build correctly.

DSL Tools

• We fixed a few bugs in the runtime, in particular, adding an element to a compartment shape could select the previous element instead of the newly added element when the compartment mapped to a derived relationship, which was incorrect.
• We updated the DslProjectMigrationTool used to migrate VS2010 DSL Tools solutions to Visual Studio 2012. It is still located under
• There is a slight API change in in Microsoft.VisualStudio.Modeling.Sdk.Integration.dll: the IModelBrowserHost interface has a new member ResizeToMeasure. This interface is implemented by the PickerDialog, as a User Interface for the modelbus references. We don’t think that anybody has really implemented this interface apart from us for the TFS workitem linking to models and model elements, so we don’t think that this really break anybody. But I preferred to mention it.

Architecture designers extensibility

• We have fixed UML designers project template VSIX following-up a change in the VSSDK,
• We have added the Layer diagram extensibility project templates. See Extending Layer Diagrams

Code Index SDK

• The code index SDK has a new loader indexing PDB files. it retrieves source file, and line number for methods body, and the method calls.
• the schema of the code index has slightly changed:
1. addition of the source file and line information (to store the information of the PDBs)
2. In Beta, Events were linked to Method definitions by AddMethodDefintion and RemoveMethodDefinition. Now there are MethodDefinitions (collection)
3. In Beta Properties were linked to MethodDefinition through GetMethodDefinition and SetMethodDefinition. Now there is a collection of assessors named AccessorMethodDefinitions
• We have, therefore, updated the code index samples. In particular if you bulk index assemblies, the PDB will be indexed, and you will get source and line information in the IgnoredTests sample
• We have added a new sample dumping to text files the public API of indexed assemblies (See How to discover and output the public API of an assembly).
• The code index database, which used to be named Repository is now named Microsoft.VsCodeIndex, to avoid collisions with user databases.
• We have changed the msbuild property name describing the name of the database when bulk indexing assemblies, it used to be named RepositoryDb and is now named Repository its default value was also changed to Microsoft.VsCodeIndex.

In Visual Studio 2010, we released the Dependency diagrams, which enabled you to visualize the dependencies between assemblies, namespaces, types or members through directed graphs. In Visual Studio 11 Ultimate, the experience around these architecture diagrams has improved a lot. There are many goodies, among which a fantastic incremental layout, and the possibility to do some diagram touch-up ; we’ll discuss the features in details in the next coming days/weeks. But what you will probably immediately notice is that now, when you use Architecture | Generate Dependency Graphs | For solution, you’ll be able to generate a dependency diagram for really huge Visual Studio solutions. We have considerably improved the performance and even more importantly the scalability of the Dependency graphs. However, that’s probably not the only way you’ll want to understand existing code : you will also want to start from a particular code element you are interested in. This is why we also enabled you to create diagrams from a selection in the solution explorer (we added a drop-down button in the solution explorer toolbar that show-up when you select code elements to “graph” those), and then ask questions from the representations of the code elements in the diagram (using the Show | contextual menu on the nodes of the graph), or pivots in the solution explorer.

… because they are queried from the code index

At the heart of these scalability and performance improvements, is the code index. Each time a diagram representing code elements is built, the corresponding assemblies are indexed in the code index (if they need to be). The code index is then used as a cache to query all the needed information. In the Architecture diagrams, the information which is indexed is limited to what is in the solution, but it is also possible to pre-populate the cache using build tasks that we released part of the VsVmSdk. It is also possible to leverage the information which is in the cache, as well as to create new contextual queries.

The code index SDK

The code index SDK gives you the opportunity to control the indexing, and to access the data which is in the cache. In the next few days, I’ll explain more about code index SDK.

Meanwhile, have fun with Visual Studio 11 Beta, and stay tuned !

As in Visual Studio 2010, this SDK still contains the DSL Tools, and an updated migration tool for your DSLs, and the build rules used to integrate T4 code generation to a build. It still contains the project templates that you can use to extend the UML designers of Visual Studio Ultimate. But it also contains a new component : the Visual Studio Ultimate code index SDK

Where can I find Samples and Documentation?

For samples and pre-release documentation, please visit the following page on Code Gallery: https://code.msdn.microsoft.com/vsvmsdk. We will progressively post samples there about the new feature.

Here is how to do to get unique name for reference relationships across the model. This is also the opportunity of explaining how to use the Name providers.

Let’s suppose that I have a simple DSL named “GloballyUniqueRelationshipName” which I unfolded from a Minimal language:

1. Add a Name property (of type String) to the ExampleElementReferencesTargets Relationship
2. Set the IsElementName property of this Name domain property to True (using the property window)
3. In the DSL explorer, set the UseFullForm property of the ExampleElementReferencesTargets serialization under the ExampleElement in the Xml Serialization behavior to true (because now our relationship has domain properties) as shown on the picture below:
   
4. In the DSL project, add a custom code folder in which you will add a new class named MyNameProvider, with the following content:
   
   

   using System;
   using System.Collections.Generic;
   using System.Linq;
   using Microsoft.VisualStudio.Modeling;
    
   namespace Company.GloballyUniqueRelationshipName
   {
    /// <summary>
    /// Custom name provider that ensures that every link instance has a unique name
    /// </summary>
    internal class MyNameProvider : ElementNameProvider
    {
     public override void SetUniqueName(ElementLink link, DomainRoleInfo indexingDomainRole, string baseName)
     {
      if (link == null)
      {
       throw new ArgumentNullException("link");
      }
    
    
      baseName = "MyBaseName";
    
      IDictionary<string, ModelElement> allSiblings = link.Store.ElementDirectory.FindElements(link.GetDomainClass())
                                                                              .Where(l => l != link)
                                                                              .ToDictionary(l => l.GetDomainClass().NameDomainProperty.GetValue(l).ToString());
    
    
      if (this.DomainProperty.PropertyType == typeof(string))
      {
    
       this.SetUniqueNameCore(link, baseName, allSiblings);
      }
      else
      {
       this.CustomSetUniqueNameCore(link, baseName, link.Store.ElementDirectory.FindElements(link.GetDomainClass()));
      }
    
     }
    }
   }
   
   

5. In the DSL Explorer, add a new external type (right clicking on the root node), named MyNameProvider and of namespace Company.GloballyUniqueRelationshipName
   
   
6. Change the ElementNameProvider property of the Name domain property of your ExampleElementReferencesTargets to MyNameProvider 
   
   
7. You are done!
   If you run your DSL in the experimental hive, the links you will create will be named “MyBaseName1”, “MyBaseName2”, and so on.

Note that this sample can be improved to apply this processing to links of a given class only (here we apply it to every links)

New improved documents and sample available

There is a bug in the ProvideCodeGeneratorAttribute, which breaks VSIX deployment because it generates absolute codebase in .pkgdef instead of Codebase relative to $PackageFolder$. This bug can be worked-around by not using the ProvideCodeGeneratorAttribute but adding a second pkgdef file in your project with the information that this attribute would generate

The problem

Here is how to repro this problem:

When you build your package, the ProvideCodeGenerator  attribute will generate some registration information for Visual Studio to take your custom tool into account. However, because of the bug, it generates a Codebase in the .pkgdef file which is absolute:

"CodeBase"="file:/// ... path on dev machine ... /DslPackage/bin/Debug/My.DslPackage.dll"

instead of relative to the $PackageFolder$

"CodeBase"="$PackageFolder$\My.DslPackage.dll"

thus preventing the code generator being deployed by VSIX (which would work if the registration attribute generated a codebase relative to $PackageFolder$ in the .pkgdef)

Workaround

Happily, a package can have several pkgdef files. The idea of the workaround is, in the DslPackage project, to add a new file named “CodeGenerator.pkgdef”, and ensure the following properties in the solution explorer for this file:
- Set Build Action to Content,
- Set Copy to Output directory to Copy if newer
- Set Include in VSIX to true

The content of the file must be something like the following (replacing the name of the custom tool its GUID, its comment, the class name for the custom tool, and the assembly name)

[$RootKey$\Generators]
[$RootKey$\Generators\{FAE04EC1-301F-11d3-BF4B-00C04F79EFBC}]
[$RootKey$\Generators\{FAE04EC1-301F-11d3-BF4B-00C04F79EFBC}\MyCodeGenerator] @="Custom tool that generates C# files based on .xxx files"
"CLSID"="{38BF483F-F6AC-468C-8826-C7DDF6ECED98}"
"GeneratesDesignTimeSource"=dword:00000001
[$RootKey$\CLSID]
[$RootKey$\CLSID\{38BF483F-F6AC-468C-8826-C7DDF6ECED98}]
@=" Custom tool that generates C# files based on .xxx files"
"Class"=" CompanyName.LanguageName.MyCodeGenerator"
"InprocServer32"="$WinDir$\SYSTEM32\MSCOREE.DLL"
"ThreadingModel"="Both"
"CodeBase"="$PackageFolder$\CompanyName.LanguageName.DslPackage.dll"
[$RootKey$\Generators\{FAE04EC1-301F-11d3-BF4B-00C04F79EFBC}\.myLanguage] @="MyCodeGenerator"

For more details, please refer to the Dsl Tools Lab for VS2010, in chapter 4: code generation (pages 20 to 23). It includes a complete end to end example of this.