During the development of our Blueprints we can sometimes use a little extra help to understand what is really going on. It turns out that if we add a Registry setting called ‘EnableDeveloperFeatures’ under the ‘HKey_Local_Machine\Software\Microsoft\Blueprints’ key and set its value to ‘true’ we get a few extra features enabled in the Blueprint Manager that might help understand (debugging) Blueprints . In the screenshot below we can see the checkboxes that become visible after we have added the ‘EnableDeveloperFeatures’ setting to the Registry. The checkboxes are read only in the Blueprint Manager dialog but can be set through the Registry.

As we can see, the ‘Custom Menu Filter’ checkbox is checked which means custom menu filters are enabled by default for our Blueprints. We can disable this feature by adding a ‘DisableCustomMenuFilters’ setting under the ‘HKey_Local_Machine\Software\Microsoft\Blueprints’ key and set its value to ‘false’.

To enable logging in the Blueprint Manager we can add the ‘BPMLogging’ setting to the Registry and set its value to ‘true’.

In an earlier post I demonstrated how to create a custom menu filter. After adding a ‘MenuDebugging’ setting to the Registry and set its value to ‘true’ we can see that Blueprint Manager now logs (output window) that it actually detects the custom menu filter that we created and also determines if it should be visible or not.

Hopefully, enabling these features help a little during the development of your Blueprints…

For one of the Blueprints I am currently writing I had to add a menu item that enables the Blueprint user to execute a specific task (command). Adding menu items to a Blueprint is pretty easy by using the Blueprint configuration dialog. As we can see in the screenshot below we can also set the ‘visibility for the menu item by specifying a menu filter in the ‘Visibility box’ on the dialog.

The current Blueprints CTP comes with a few ‘built-in’ menu filters like: Project=roject name, FolderEndsWith=folder name, etc. (complete list can be found in de Blueprints documentation). Of course I needed a menu filter that wasn’t available out of the box. Unfortunately the documentation doesn’t say anything about adding custom menu filters but luckily a little experimenting (and Reflector ;)) was enough to get this to work.

Here are the steps to implement your own custom menu filter: 

The first thing to do is to simply add the name of your new custom menu filter in the ‘Visibility’ box of the menu item you want the custom menu filter to be applied on. In this example we also pass a custom argument (‘BlaBla’) to our custom menu filter.

The second step is to actually implement the custom menu filter. This can be easily done by adding a ‘Command Extension’ project to your Blueprint solution (Blueprints menu –> Add Command Extension). This project already implements a post build event to make sure the .dll that hosts your command extension is copied to the correct location to let Blueprint Manager find it during execution of your Blueprint.

for this example we can delete all default files in the extension project and add a new class to this project that implements the ‘IMenuFilter’ interface (add a reference to the ‘Microsoft.SoftwareFactories.BASMAPI.dll’ assembly that can be found under the Blueprint installation directory).

In this class, the ‘FilterSupported’ method is used to decide whether a  custom menu filter is supported in our Blueprints. Àll we have to do in this method is return ‘true’ for the custom menu filters (name) that we want to support in our Blueprint. (note that we can handle multiple custom filters here).

The ‘Visible’ method is used to decide whether the menu item that has our custom menu filter applied should be visible or not. The screenshot below demonstrates a, not very useful (and not bulletproof), implementation of a custom menu filter that only shows the menu item in case the Blueprint user right clicks the Solution (Solution Explorer) and the name of the selected Solution starts with the parameter supplied to the custom menu filter (‘BlaBla’ in this case).  As said, not a very useful filter but it hopefuly demonstrates what can can be done here.

After we finished the ‘Visible’ method, we are done implementing our custom menu filter and all we have to do is make sure the Blueprints Manager knows about our custom menu filter. How?

As we can see in the screenshot below, the menus that we define in our Blueprint configuration dialog (see above) are stored in the ‘config.xml’ file of our Blueprint (located in the properties folder in our Blueprint project).

At some point, the Blueprint Manager parses this config file, searches for custom menus, detects the ‘MyCustomMenuFilter’ that we specified in our menu item and notices it isn’t one of the ‘built-in’ menu filters. At that time the Blueprint Manager checks if any additional ‘resources’ are registered for our Blueprint that might host an implementation of the ‘IMenuFilter’ interface. To make sure the Blueprint Manager can find our extension, we register our custom menu filter by adding the following (screenshot below) to the config file of our Blueprint.

After that, if the Blueprints Manager detects a menu filter that is doesn’t recognize, it will search its additional resources and find our custom menu filter implementation. It will then call the ‘FilterSupported’ and ‘Visible’ methods on our ‘CustomMenuFilters’ class to decide whether or not the custom menu item is supported and under what circumstances display our menu item.

When working with a Blueprint to deliver a product, we very often start with unfolding a solution/project structure (template) that reflects some architectural guidance. When building a Blueprint, we have a few options for unfolding templates within our Blueprint (that we can set through configuration as displayed below). The option ‘None’ obviously doesn’t unfold a template at all, ‘Auto-generated’ unfolds a predefined project template (C# class library) and ‘User-supplied’ provides us with the possibility to define our own solution/project templates. (The guidance that comes with the current release of Blueprints does a pretty good job describing these three options)

However, sometimes we need even more control before, during or after template unfolding (ie create folder structures, complex dialogs, Add to source control, etc.). Luckily, there is another mechanism that we can use for this scenario that gives us full control!

We can add a ‘Command Extension’ (right click on your Blueprint and select ‘Add Command Extension’ from the Blueprints menu) and write an extension that unfolds our custom project templates. 

Adding a Command Extension to our Blueprint gives us a new project in our Blueprint solution. This new project already contains an example extension that we can modify to implement our custom unfolding logic.  Below, a simplyfied implementation of this modified Command Extension is given that uses the custom ‘MyTemplate.vstemplate’ template and unfolds that to a (hard coded) location.

After we fully implemented our extension, we can add this Command Extension to the commands collection of our Blueprint (More info on how to add commands can be found in the Blueprints documentation).

The real ‘trick’ here is to name the command ‘INIT’ which will force the Blueprints Manager to execute the command automatically for us when unfolding our Blueprint to a (empty) Visual Studio solution. Also, don’t forget to set the ‘Template’ option in the Blueprint configuration dialog to ‘None’! Note that we also added a switch statement to our implementation of the Command Extension to only execute the template unfolding in case the ‘INIT’ command gets executed.

With this in place we can write complex ‘vstemplates’, that include WizardExtensions to collect user input and rely on the Blueprints Manager to execute our ‘INIT’ command to unfold these templates when developers add our Blueprint to their Visual Studio solutions.

Those of you interested in software factories should check out the new Blueprints Manger and Sample Blueprint which were released on the Blueprints Codeplex site right after PDC 2008. Jack Greenfield and Michael Lehman hosted the ‘Blueprint booth’ at PDC 2008 where they demoed this latest release. Blueprints represent the next generation Software Factories and solve many of the authoring and deploying issues that we have experienced with GAT/GAX based software factories. In addition, they add some great features (some of them demonstrated in the Sample Blueprint) to the factory space like :

• Multiple interacting Blueprints
• Blueprint Composition
• RSS based updates
• WF-Process structured workflow
• WF-Commands - workflows which can automation developer tasks within Visual Studio
• Custom Menu Filters - allowing menus to appear when the conditions are right
• Code generation using the T4 Template system
• Custom extensions - assemblies which can interact with the user and Visual Studio

Details on Blueprints can be found in the ‘Introduction to Microsoft Blueprints’ paper (link currently broken but will be fixed soon!) that can be downloaded from the Blueprints homepage on MSDN.

More information, samples, screencasts on factory authoring, planning, etc. will be available in the coming period so you better make sure to get back to the Blueprints home on Codeplex reguarly! (expect some info on this blog too ;))

Last week at PDC 2008, OSLO was announced as the new platform for model driven development. OSLO is composed of a language called ‘M’, a tool called ‘Quadrant’ and a repository. After the announcement of OSLO I spoke to several people asking me my opinion about the difference and/or overlap between OSLO and the Microsoft DSL Tools, which is the current toolset for building visual DSL’s. Obviously, at that moment wasn’t very clear for a lot of people including me. After some more discussing and thinking I have things more clear:

In the session of Douglas Purdy and Vijaye Raji, called ‘A lap about OSLO’, Douglas mentioned three types of modeling (models). First, we have ‘drawings’ which are primarily used to communicate with others. Perfect tools for creating drawings are whiteboard or tools like Visio. Second, we have ‘Model Assisted’ models which are used to understand or manipulate code (or other artifacts). Last, we have ‘model driven’ where models are directly executed by a runtime and drive runtime behavior of applications.

Obviously, OSLO is all about ‘Model Driven’ and driving runtime behavior. When looking at the new Team Architect (UML) diagrams in VS 2010 CTP we can see that DSL Tools fit perfectly in the ‘Model Assisted’ world. All new diagrams in Team Architect are build on the DSL Tools and especially in combination with (future) technology, often referred to as ‘designer bus’, DSL Tools are very powerful in scenarios where artifact generation is involved.

So, currently each platform supports a different approach. Possibly there are some overlaps and only Microsoft can tell how both platforms evolve, coexists and/or eventually (partially) integrate?

In the meantime, I will start experimenting with OSLO and definitely continue to work with the DSL Tools to get the best of both worlds!

Service Factory Contrib Project is live! Yesterday, Don Smith published the site that will (hopefully) soon host a lot of community extensions for Service Factory. Hernan de Lahitte already contributed the long waited for "Import from WSDL" feature and I donated a version of Service Factory that includes VB.NET code generation from your models.

I will upload some other extensions in the coming days but for now, if you have anything to share, please read all about p&p contrib projects, follow the sign up process and we will make sure you can publish your contribution soon.

For those of you who have been wondering what is happening with Software Factories lately, have a look (and subscribe) at the new team blog for Software Factories. In this post, Jack Greenfield outlines the plans the team has to move the Software Factory Initiative forward. Also Jezz announced to be back and promised to post a bit more (I really should do the same...).

So, great news for everybody interested in adopting Software Factories! (in the 'near' future)

I just received an email of somebody who got stuck trying to follow the steps I described in this previous post. In this post I explained how to write a "VSServiceManager" (ExampleLanguageDesignerServiceManager) and register it in the Software Factory Schema file. However, when trying this example in the Rosario April CTP you will notice that the "Software Factory Runtime" dlls are no longer there (no further comments on that...). The good news is that Backplane is still available and we can also register our VSServiceManager with Backplane by adding the following snippet to the "Backplane.config" file (PrivateAssemblies folder).

I got a few other backplane related questions so I decided to clean up some of my experimental code and make that available for download (together with a few posts to provide some more details). Expect something in the coming days?!

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...

In a previous post we have seen the Application Explorer acting as a starting point for our software factory. To continue our journey, let's have a closer look at this Application Explorer. For example, where does it get the list of installed software factories from? 

A quick look at GAC on our Rosario VPC reveals a few new assemblies that (based on their name?!) might have something to do with software factories. these are:

• Microsoft.VisualStudio.SoftwareFactories.Runtime.dll
• Microsoft.VisualStudio.SoftwareFactories.Runtime.VSHost.dll
• Microsoft.VisualStudio.SoftwareFactories.ApplicationExplorer.dll 

The Application Explorer is obviously implemented in "Microsoft.VisualStudio.SoftwareFactories.ApplicationExplorer.dll". Currently, no (public) documentation is available so we have to use reflector to find out this assembly holds the "ApplicationExplorerPackage" (inherited from Microsoft.VisualStudio.Shell.Package) which is using the "FactoryManager" (more on that later). Besides the "ApplicationExplorerPackage" this assembly also implements the ApplicationExplorerToolwindow and the ApplicationExplorerControl which are representing the UI of the Application Explorer in Visual Studio.

Digging a little further, we can find out the "FactoryManager" (implemented in Microsoft.VisualStudio.SoftwareFactories.Runtime.dll) is using the "FactoryDescriptorsLoader" to search the Registry for installed software factories on the machine.

please note more classes are involved in this "discovery process" but I am only focussing on the high level to make this post not more confusing than it probably is already. I am sure you know how to use reflector yourself if you are interested in more details ;)

As we can see in the screenshot below the Registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\SoftwareFactories) in the Rosario VPC holds information about two installed software factories. By looking at the Service Factory node we can see the Registry contains the Name, Description, InstallDir, Version and SchemaFileName of the software factory.

SchemaFileName?! hmm....is this in anyway related to the "Software Factory Schema that is discussed in the "Software Factories" book? Below a screenshot of the Schema File for Service Factory that we can find in the "InstallDir" of Service Factory (C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies). Pretty interesting to finally find concepts like "viewpoints" and "workproducts" related to software factory implementations.  

Without going into too much detail, how does this all work?

It all starts in the "VSPackage" (inherited from Microsoft.VisualStudio.Shell.Package) that can be found in "Microsoft.VisualStudio.SoftwareFactories.Runtime.VSHost.dll". At some point a "FactoryManager" (Microsoft.VisualStudio.SoftwareFactories.Runtime) is instantiated. This "FactoryManager" is using a "FactoryDescriptorLoader" to read the Registry and to create (and cache) a collection of "FactoryDescriptor" classes. The information contained in the software factory Schema File eventually ends up as a "Factory" instance that holds the "FactorySchema" which is the root for the FactoryViewPoint, Command, WorkProducts, etc. The Application Explorer on its turn is using the "FactoryManager" to list the installed factories, the viewpoints it contains and enables us to (for example) execute the "Create Product" action that we discussed earlier.

Again, just the high level overview! There are a lot more interesting classes and concepts involved in this but it hopefully gives some basic understanding. In a next post we will try to understand the purpose of the "Commands",  "Viewpoints" and "Workproducts" that we have seen in the software factory Schema File.

To be continued...

A few months ago "Rosario November 2007 CTP" became available for download. Based on the available documentation, walkthroughs and “mini stories” we can safely conclude that this release wasn’t really build to please the software factory guys out there! However, what it *does* contain is a (limited!) version of Service Factory that works on a very early (?) version of the Software Factory Runtime. This might be interesting. Let’s have a look if this version of Service Factory shed some light about what we might expect from Rosario in the software factory space.

(Of course, this CTP is relatively old already and hopefully a new one will arrive in the coming ? but maybe we can learn something from this CTP already...)

Ok, how does Service Factory looks like in Rosario CTP? To find out we can start a new Service Factory project by using the Application Design template that can be found under the “Distributed Systems” node in the “new project” dialog.

After the template unfolded, the first thing to notice in our new solution is the new “Application Explorer”. From this new “Application Explorer” tool window we can create a “Product” that is based on the installed software factories on the machine. As we can see in the screenshots below this machine has two factories installed and one of them is “Service Factory”.

By selecting "Web Service Software Factory" and pressing "OK" in the "New Product" dialog we end up in a situation that is similar to the one we are familiar with when using the current Service Factory. We can create a "New Model" and use the factory "as usual" from there.

Digging a little further in this CTP tells us (Add or Remove Programs) GAX is installed and GAT isn't! Further we can see that besides the package that looks like the "normal" Service Factory a package called "Web Service Factory Application Designer Integration" is installed.

A quick look at the installation location of Service Factory (C:\Program Files\Microsoft Service Factory V3) tells us that this version of Service Factory indeed looks like an ordinary software factory that is build on top of GAX. The installation folder still contains recipes, vstemplates, T4 templates, etc.

What does this mean? Can we use our current software factories (or at least parts of them) in Rosario? If so, do we benefit from anything new? How does Service Factory integrate in the Application Explorer? Where do we need this "Web Service Software Factory Application Designer Integration" package for? Is the "Software Factory Runtime" in this CTP of Rosario only implemented by GAX?

To be continued...

It is there, a new Software Factory Community Portal!

 Martin Danner, Jezz Santos and myself have been talking about starting up a community around software factories for some time and now we finally did it.  

This community is all about software factories, domain specific languages, Visual Studio Extensibility and other related topics. The portal includes a forum, blog aggregation, news and additional resources like links, articles, books, etc. We haven’t finished adding all resources yet but registered users are allowed to add new resources, provide ratings and add comments.

So, please join us there, start discussing and participate in building a community around software factories!

We already announced the availablility of part 1 in our "Packaging & Building Software Factories" series here. Today, part 2 called Automated Builds with Team Foundation Server is also published. Enjoy!

Finally, part 1 of  our (short) series about "Packaging and Building Software Factories" is published on MSDN. The goal of these articles is to help you with packaging your software factories and implementing a team build with Team Foundation Server. As you will see this isn't always as straight forward as you might expect! These are the parts in this series:

• Part 1 - Packaging with Visual Studio 2005
• Part 2 - Automated Builds with Team Foundation Server 

I co-authored the series with Jezz and my colleague Rene. Thanks guys! Also, many thanks to our reviewers: Gareth, Pablo, Attilah, David and Mark Nichols !

We also included reference implementations for you to download and created a CodePlex project (for part 2 in this series) that we will use to publish some additional MSBUILD tasks and 'utilities'.

Stay tuned for part 2 and let us know what you think!