In a previous post I quickly mentioned the conceptual "Designer Bus" which is currently represented by "Backplane" in the Microsoft.VisualStudio.ToolIntegration.Backplane.dll" assembly. I stated we can use Backplane to "maintain" all kind of references between objects, model elements, designers, tool windows, etc. In this post we will dive a little deeper to see how we can use Backplane to get a reference to a  model element in a Domain Specific Language.

Anyone familiar with Domain Specific Languages (DSl Tools) probably also heard of the Designer Integration Powertoy (DIS). DIS can be used to create (and resolve) references between model elements withing or accross languages. Unfortunately the solution that DIS is offering is pretty limited. Hopefully Backplane will do a better job!

Here is high level overview of the steps I took to "investigate" this.

First I used the Microsoft DSL Tools to created a simple Domain Specific Language called "ExampleLanguage" which is based on the "Minimal Language" template. As you can see in the screenshot below this is really simple DSL but enough for this test. 

 Second, I created a class called "ExampleLanguageDesignerServiceManager" that inherits from "VSServiceManager" (Microsoft.VisualStudio.ToolIntegration.Backplane.VSHost.dll). Below you can see what this class looks like. 

(note: "ReferencedDataContracts" and "ServiceContract" have nothing to do with the concepts we know from for example WCF)

The only important thing to remember from this class (for now) is the "CreateService" method that returns a "ExampleLanguageDesignerService" that is displayed below. This class inherits from VSService (Microsoft.VisualStudio.ToolIntegration.Backplane.VSHost.dll) and basically wraps my "ExampleLanguage" DSL. For example, you can see it has a (private) property for the "Diagram", "DocData" and "ExampleModel" which is the root of my DSL. (It does have a lot more butI skipped that in this screenshot.) 

 An interesting method in the "ExampleLanguageDesignerService" class is the "GetExampleModelElements" method which returns a ReadOnlyCollection of "ReferencedExampleElement". As you can see in the screenshot of the DSL defintion above, "ReferencedExampleElement" isn't part of the "ExampleLanguage" DSL so, where does this come from?

Backplane introduces the "ReferencedObject" class (Microsoft.VisualStudio.ToolIntegration.Backplane.dll) that represents an object with the capability of "being referrenced". One of the properties of "ReferencedObject" is "Reference" that holds the "location" where Backplane can find the object. What I did is, I created a "ReferencedExampleElement" class (screenshot below) that inherits from "ReferencedObject" and "wraps" the "ExampleElement" class from the DSL. The "GetExampleModelElements" method in the "ExampleLanguageDesignerService" loops through all elements in the DSL, wraps them in a "ReferencedExampleElement", adds them to a collection and returns the collection.  

 (Note: anyone interested in the source code that is needed to actually implement the above mentioned classes, have a look at "Microsoft.VisualStudio.TeamArchitect.LogicaClassDesigner.ToolAdapter.dll". This assembly contains similar classes that will help you understand the details.)

The next thing I did is I made sure the above mentioned classes get loaded by Visual Studio. To do this I included the above mentioned "ExampleLanguageDesignerManager" in one of my test factories called  "MyFirstRosarioFactory". The screenshot below shows the Software Factory Schema for this factory.

 As we can see I defined the "ExampleLanguage" viewpoint and registered the "ExampleLanguageDesignerManager" which ensures at some point it gets loaded by the "Software Factory Runtime". In the following code example (that I implemented in a command in my factory) we can see I am using Backplane to get a reference to the "ExampleLanguageDesignerServiceManager". After that we can use the "ExampleLanguageDesignerServiceManager" to create an instance of the "ExampleLanguageDesignerService". Then we can use the "ExampleLanguageDesignerService" to get all elements (ReferencedExampleElement) from a specific dsl model (without using DIS!)

 (note: some code is missing in the above screenshot. for example, we have to define a "scope" to define the solution, project, item, etc. where we are interacting with) 

I already mentioned my "ReferencedExampleElement" class inherits from the "ReferencedObject" class implemented in Backplane. This "ReferencedObject" object has a property called "Reference". When running the above code in debug mode I can see that the "Reference" property of "MyElement" (code snippet above) has a value of

"backplane://C:\\Dev\\MyFirstFactory\\MyFirstRosarioFactory1.pdef/MyCompany.ExampleLanguageToolAdapter.ExampleLanguageDesignerServiceManager/9d375fb7-bccd-4d03-a6ec-20340517d360\\MyModel.mydsl/6568ccec-604f-40c3-b143-9962a0901807""

 

The cool thing of Backplane is that once we know the "Reference" of an object we can ask Backplane to resolve it for us with code that looks like:

To be continued...

In a previous post we mentioned the existence of a "Software Factory Schema" file for an installed factory in our Rosario CTP. We now know, at some point, a "Factory" instance is created from this file that holds all the information that is stored in this schema file. Let's have another look at the software factory schema file of Service Factory to see if we can learn something more from this.  

One of the things to notice in this schema file is a viewpoint that is called "ServiceRootViewPoint". This viewpoint is the so called "root viewpoint" for this software factory. We can also see that there is another viewpoint within this root viewpoint that is called "ServiceContractDesignerViewpoint". As we can see, the root viewpoint holds a "Command" (ServiceRootCreationCommand) that contains a "CommandType" and a "CommandImplementationType. In this case both are implemented in the "Microsoft.Practices.ServiceFactory.Commands.dll" that we can find in the "InstallDir" (C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies) of this factory.

So, where do we need this CommandType and CommandImplementationType for? In a previous post, we have seen that when we executed the "CreateProduct" in the Application Explorer  

it popped up a dialog where we could select the software factory where wanted to create a product from. 

When we select a software factory in this window and hit OK, the ApplicationExplorer (and some helpers) retrieves the root viewpoint of the software factory and finds the Command that is associated with this. At that point the Command,implemented as a "FactoryCommand" is transformed into a more general "Command" that is implemented in "Microsoft.VisualStudio.ToolIntegration.Backplane.dll".

This is actually *very* interesting because this assembly implements a concept that is sometimes referred to as the "DesignerBus" (it is called Backplane at this moment) which hopefully makes it possible to, for example, implement references between models, references between models and designers, toolwindows, get a reference to a Service in VS.NET,etc.  It can actually be used to glue everything together ;) Anyone familiar with the DSL Tools knows that at this moment we only have DIS to create references between models and only in a very limited way. Maybe Backplane can help here! (More on this very exiting stuff in another post).

Let's continue with our Command... After the FactoryCommand is "converted" into a general command it gets executed. Below we can see a code snippet from the "Execute" method of the "ServiceRootCreateCommandImplementation" from the root viewpoint of Service Factory. The code might look funny to you but this is just because it is produced by reflector and not by me ;) You can see that "Backplane" is used here to get a reference to the "RecipeManager" and "DTE". Perfect! 

What we can also see is that basically all that happens here is, get a reference to the a Guidance Package and unfold a template (model.vstempate) to set the initial structure of our Service Factory solution. Please note that "model.vstemplate" is just a normal  .vstemplate that is located in the source tree of Service Factory (C:\Program Files\Microsoft Service Factory V3). This means, in Rosario CTP we can create command, hook it up to the root viewpoint of our software factory and Application Explorer makes sure it gets executed to set, for example, the initial structure for the product we are building in our factory. From there on, all "normal" (old) Service Factory V3 recipes should work as expected! (Decide for yourself if that is good or bad news)

Below you can see what Application Explorer looks like after we executed the "Create Product" and selected the "Web Service Software Factory" in the "New Product" dialog. Also note the "ServiceContractDesignerViewPoint" folder that we have seen in the software factory schema above.  

Solution Explorer looks like this. Note the .pdef files! (More on that later)

To be continued...