I like to invite you to try this version of the product, and experience the updated interface and new features.

Why should you try it:

• Visual Studio 2010 support with a new updated user interface
• *new* Support for VC++ projects
• Create notes from Visual Studio tasks
• Create notes from compiler, FxCop and StyleCop warnings
• Convert notes to Visual Studio tasks
• Email notes
• Edit in place

You can download it from here

Please try it out and don’t forget to send feedback

Pablo

I want to thank my MVP lead Fernando Garcia Loera and the rest of people involved in the evaluation process for the recognition of my community efforts.

�

Thanks Microsoft!!!

Pablo

This time I will talk about the new DSL extensibility feature in DSL VS10. This feature allows a model to be extended after it is deployed. This opens a huge number of possible scenarios including third party ones.

In this part I will cover the core changes and concepts in the new version of DSL to support the extensibility feature.

A DSL extension is indeed another DSL. This means that a DSL is extended by creating another DSL.

From now on I will refer to them as the extendee DSL and extension DSL respectively.

These are just a couple of extensibility points that can be provided (just to mention some of them):

• Add new domain classes / domain relationships
• Add new extension elements to existing model elements
• Add new commands
• Add modeling rules

But the real thing is that we can completely override the behavior of the extendee DSL. What really happen behind the scenes is that the extendee domain model plus all the extension domain models found are being loaded into the same store.

The new ExtensionElement domain class

In the runtime there is a new abstract class called “ExtensionElement” that inherits from the well known ModelElement. This class is used to represent an extension to a model element. It also called “MEX”.

The new “Extensions” domain relationship

The ModelElement was updated and now includes a new “Extensions” domain property. This is basically an embedding relationship between ModelElement and ExtensionElement.

MEX extension methods

Under the new Microsoft.VisualStudio.Modeling.Extensibility namespace, there are a couple of useful extension methods for the ModelElement class to do CRUD operation over the ModelElement extensions.

Next part : MEF, extension providers and how extension domain models are being injected

Pablo

In the previous version of the VS SDK, when we create an Isolated Shell project, there is a command to specify Shell Dependencies:

When we compile the project, those dependencies plus any pkgdef file are being copied to the \PackagesToLoad subfolder.

Now is VS10, the Shell Dependencies command is gone and the way to add dependencies is via the References button. (which seems more natural to me)

Another change is that the PackagesToLoad subfolder was renamed to “Extensions” to be sync with the full IDE extension naming thing.

Pablo

Creating a custom instance/hive for Visual Studio is easier than ever. In this post I will show the details to create a fictitious “pga” instance and configure our VSX development environment to point to it.

This can be useful in some testing scenarios or when we just don’t want to reset the experimental instance to test something.

Creating the pga instance

To create a new instance we use the CreateExpInstance tool:

%VSSDK_Installdir%\VisualStudioIntegration\Tools\Bin\CreateExpInstance.exe /Reset /VSInstance=10.0 /RootSuffix=pga

Once we do that the following directory is created:

%LocalAppData%\Microsoft\VisualStudio\10.0pga\Extensions\

And all existing extensions in the main hive are copied to:

%LocalAppData%\Microsoft\VisualStudio\10.0pga\Extensions\Extensions-10.0

Redirecting the VS SDK msbuild target to the pga instance

Every time that we compile a VSPackage project the Microsoft.VsSDK.targets msbuild target is executed doing all the necessary steps to deploy our extension.

But the default behavior is to deploy the extension under the experimental instance. To override that behavior we need to include the following property in the VSPackage csproj file:

<PropertyGroup>
  <VSSDKTargetPlatformRegRootSuffix Condition="'$(VSSDKTargetPlatformRegRootSuffix)' == ''">pga</VSSDKTargetPlatformRegRootSuffix>
</PropertyGroup>

Executing VS pointing to the pga instance

To point Visual Studio to a particular instance we just use the /rootSuffix switch:

%VS_Installdir%\devenv.exe /rootSuffix pga

Or we can just enable the F5 experience from the Debug tab in the project properties:

Pablo

Another new feature of the new version of the DSL toolkit is the ability to locks certain operations in a DSL. The idea is that we can define locking policies for a DSL and those policies are executed at runtime to constraint specific operations such as Add/Delete/Update etc.

These locking policies can be defined at three different levels , Store, Partition and ModelElement respectively.

Defining our own locking policies

It is really simple to create our own policy class, we just need to create a class that inherits from ILockingPolicy.

Then we need to define the locks that we are going to return, and for that we have three levels of granularity:

• Store
• Partition
• ModelElement

Locks are transitive following the “Store –> Partition –> ModelElement” object hierarchy.

That means that if we set locks at the Store level, those locks also apply to the Partition and the ModelElement levels.

The lock types are:

�

public class MyLockingPolicy : ILockingPolicy
{
    public Locks RefineLocks(ModelElement element, Locks proposedLocks)
    {
        return proposedLocks;
    }

    public Locks RefineLocks(Partition partition, Locks proposedLocks)
    {
        return proposedLocks;
    }

    public Locks RefineLocks(Store store, Locks proposedLocks)
    {
        // TODO: return corresponding locks and they will also apply to Partition and ModelElement
    }

}

Injecting our own ILockingPolicy

The Store class constructor sets the locking policy by querying for a ILockingPolicy service. That means that one possible way to inject our own locking policy is to override the GetService method and return our policy class:

internal partial class MyDocData
{
    private ILockingPolicy myLockingPolicy;

    public override object GetService(Type serviceType)
    {
        if (serviceType == typeof(SLockingPolicy) || serviceType == typeof(ILockingPolicy))
        {
            if (myLockingPolicy == null)
            {
                myLockingPolicy = new MyLockingPolicy();
            }

            return myLockingPolicy;
        }

        return base.GetService(serviceType);
    }
}

At runtime the DSL infrastructure will query for existing locks using a set of extension methods located in the new ImmutabilityExtensionMethods class and constraint or not an operation accordingly.

The hardware model sample

I published a sample that shows how to lock a DSL.

The scenario is that there are two personas:

• Developer: He uses the VS full IDE to author a hardware model.
• Architect: He uses an Isolated shell to review the model and cannot do any modifications to it.

The locks are being set by detecting the shell SKU.

Pablo

In the first part I covered the details of the T4 Preprocessing API.

Now it’s time to create a preprocessed text template and mimic the GAX property directive processor feature.

Let’s add a preprocessed text template. For that purpose there is a new item template in the VS10 Add new item dialog:

After we add a pre-compiled template item, we can see the output of the transformation:

As you can see, the namespace is calculated from the project default namespace property, and the tt item name is used to calculate the class name.

Using properties to mimic the GAX PropertyProcessor directive

�

After the TemplatedPreprocessor runs we end up with a template class, which is just a regular class with some helper methods to write the transformation.

These methods are similar to the ones provided in the base TextTransformation class. But to remove the dependency to the Microsoft.VisualStudio.TextTemplating.10.0 assembly those methods are now part of our template class.

To add properties that will be consumed inside the template, it is just a matter of declaring a partial class and adding them there:

namespace PreTT
{
    public partial class MyPreTextTemplate
    {
        public string MyProperty { get; set; }
    }
}

Then from within the template we can just refer to the property:

<#@ template language="C#" #>
MyProperty value is <#= this.MyProperty #>

To test the transformation we create an instance of the template class and we call the TransformText method:

public static void Main(string[] args)
{
    Console.WriteLine(
        new MyPreTextTemplate { MyProperty = “Foo” }
        .TransformText());

    Console.Read();
}

And the transformation output is :

Pablo

Gareth wrote some time ago two nice posts about the T4 Preprocessing feature:

• The Rationale behind this feature
• The basic design

This post will have two parts. The first one will cover the details of the new API and the second one will show how to create a preprocessed text template and the how to mimic the GAX property directive processor feature using partial classes.

The precompiled text template feature is really useful in scenarios where the text templates doesn’t change at run time.

Let’s say that we have an application that uses a set of templates for code generation, and those templates never change.

This is a perfect fit for precompiled templates.  Instead of deploying a set of .tt files as part of the application, we can pre-compile them and they now can be part of the main application assembly or any other component assembly.

This *drastically* improves the performance because on each transformation this is what happens behind the scenes in order to get a transformation result:

• A template processor calls the template engine that:
  • Parses the template
  • Processes the directives
  • Generates the template class
  • If the text template doesn’t cache the assemblies (CacheAssemblies=”false”) or if the application domain needs to be recycled
    • The template host creates an application domain
    • The template host resolves the assembly references that are defined in the template
    • The template host creates a transformation runner that:
      • Compiles the generated template class into a temporary assembly
      • Loads the temporary  assembly into the application domain
      • Calls the “TransformText” method that returns the transformation result
  • Else
    • The template host creates a transformation runner that:
      • Uses the cached assembly
      • Calls the “TransformText” method that returns the transformation result

With a precompiled template we skip all the steps in *bold* and we just call the “TransformText” method in the compiled template class that is part of the application or component assembly.

Also, having a precompiled template means that a transformation can run in any .Net environment without the need of having Visual Studio or the Microsoft.VisualStudio.TextTemplating.* assemblies installed.

API changes to support template preprocessing

• The following two interfaces were updated to include the new PreprocessTemplate method:

public interface ITextTemplating

{

string PreprocessTemplate(string inputFile, string content, ITextTemplatingCallback callback, string className, string classNamespace, out string[] references);

}

public interface ITextTemplatingEngine

{

string PreprocessTemplate(string content, ITextTemplatingEngineHost host, string className, string classNamespace, out string language, out string[] references);

}

• A new TemplatedPreprocessor custom tool /single file generator was added:

This new custom tool is the responsible for creating the template class at design time. This tool basically does the following:

• Parses the template
• Processes the directives
• Generates the template class

Stay tuned,

Pablo

In the first part of this series I described general concepts around the ModelBus infrastructure. In this second part I will describe the model bus service and how MEF is involved.

The ModelBus as a Service

The Microsoft.VisualStudio.Modeling.Sdk.Integration.Shell.10.0 is a VS Package that defines one core service, the IModelBus service.

The model bus service creates and uses its own MEF composition container with two directory catalogs pointing to:

• %LocalAppData%\Microsoft\VisualStudio\10.0\Extensions
• %VS10_Install_Dir%\Extensions

A DSL exports an adapter manager and provides some metadata to specify which adapter this manager manages:

[Export(typeof(ModelBusAdapterManager))]

[HandlesAdapter(“MyAdapterId”)]
public partial class MyAdapterManager : VsModelingAdapterManager
{

…
}

The main responsibility of the model bus is to find registered adapter managers, for that the composition container is used:

container.GetExportedObjects<ModelBusAdapterManager>()

In order to register a DSL with the model bus we need to do the following steps:

• Update the model definition to introduce a domain property that will hold the model reference
• Update the model serialization behavior to include the model reference serialization
• Create an adapter for the DSL
• Create an export an adapter manager for the DSL
• Deploy the DSL under extensions (done automatically at compilation time via the VS SDK msbuild target)

Stay tuned,

Pablo

One of the new main features of the new version of the DSL toolkit is the “ModelBus”. The model bus basically allows a model element to reference another model element (ModelBusReference). These two model elements could be defined either in the same DSL or in different ones. With a ModelBusReference we can do interesting model interactions such as navigating the references back and forth, performing validation across models, etc.

The ModelBus infrastructure lives in two core assemblies:

• Microsoft.VisualStudio.Modeling.Sdk.Integration.10.0
• Microsoft.VisualStudio.Modeling.Sdk.Integration.Shell.10.0

Microsoft.VisualStudio.Modeling.Sdk.Integration.10.0

As the name implies, this assembly contains concepts that are totally decoupled from Visual Studio.

The main generic concepts are:

ModeBusAdapter

Is a bridge between the model bus and the underlying model. Therefore each model has its own adapter.

It’s main responsibilities are:

• Get all references of an element type
• Resolve a reference into an object
• Get the view associated with the model

ModelBusAdapterManager

Is used to create and control the lifetime of adapters.

It’s main responsibilities are:

• Create adapters
• Create reference to a model
• Return the list of supported adapters
• Return the list of exposed element types. An exposed element type is an element that can be referenced by another element

ModelBusReference

Encapsulates information about a reference in the model bus. It is composed of:

• Adapter reference
• Adapter id
• Model display name
• Element display name

It is being serialized as:

ModelBusAdapterReference

Represents the base class for adapter references

ModelBusView

Allows a client to manipulate the design surface of the model (if applicable)

It’s main responsibilities are:

• Open view
• Close view
• Show view
• Hide view
• Select UI elements

Then we have a set of derived classes that are specific to DSLs:

• ModeBusAdapter<- ModelingAdapter
• ModelBusAdapterReference <- ModelingAdapterReference

ModelingAdapter

Represents the base class for DSL based adapters. In this case the model is a DSL model.

ModelingAdapterReference

Encapsulates information about a model element reference, it is composed of:

• Model element id
• View id
• Model file absolute path

It is being serialized as:

Microsoft.VisualStudio.Modeling.Sdk.Integration.Shell.10.0

In this assembly there are concepts that are coupled to the Visual Studio infrastructure.

VsModelingAdapterManager

This adapter manager introduces the notion of document handlers that knows how to handle a DocData concept.

VsModelingView

This implementation is tied to the DocView concept.

Stay tuned,

Pablo