The Layer Diagram

The layer Diagram in VS2010 Ultimate is a great tool for validating your applications architecture. If you already have an application and you would like to see how your team has done following your prescribed architecture. Check this out.

Open your application in Visual Studio.

Then create a new Layer Diagram using the Architecture – New Diagram menu in Visual Studio Ultimate.

By dragging over layers from the tool box create a Layer Diagram that represents the architecture of your application.

Then Drag the components from your application in the solution explorer to the appropriate layer in the diagram. You can then open the Layer Explorer to see what layer everything is assigned to. (You can drag anything from a project to a single file.) Notice the numbers in the Layer diagram representing the number of items in that layer.

 

You could have created dependencies in the diagram to show which layer can call which layer. Since we are pulling in an existing app we want to see if it was written following our architecture. Therefore Right click on the diagram and select Generate Dependencies.

So here is how our application came out.

Most of the dependencies are fine. However there seems to be a lot of calls directly to the Data Layer. That is not good, but happens when the architecture is not validated periodically. click on the dependencies that are incorrect and press delete to remove them. Here is the Layer diagram as we intended it.

Now right click on the diagram and select Validate Dependencies.

This will generate errors and warnings where the application does not follow the architecture. So the Dependencies generated in the previous step now generate errors in the application.

From the error list you can generate work items in TFS to get these discrepancies fixed.

The bug will contain layer diagram that generated this error and the details of the invalid dependency.

The Next Version of VS and TFS

While we have been enjoying the fantastic features made available in VS and TFS 2010, Microsoft has been busy working on the next version. The ALM story just keeps getting better and better.

Last week at Teched MS showed off a lot of the new features we can expect to see in the next release. Below is a SpeakFlow presentation with demos to help tell the story.

A SpeakFlow is a Silverlight-powered way of delivering rich, interactive content. This SpeakFlow allows you to follow the lifecycle – from development to operations and back again – and view short demonstrations of how Visual Studio vNext will help you embrace better application lifecycle management. start at the top with the  “STORYBOARDING” video and then following the circle counter-clockwise.
Tip: To go up a level after drilling in, use your mouse wheel or the UP key on your keyboard.

Click on the image below to take a look.

Architecture with Visual Studio 2010 At The Movies

This is just a quick follow up post from my demo at Visual Studio 2010 At The Movies last week. Thanks for everybody who came out, especially those from out of town.

I didn’t use any slides but I thought about recording my demo here. I may still get to that, but in the meantime, here are a few resources that will help you learn more about the architecture tools in Visual Studio 2010 Ultimate Edition:

  • The .NET Pet Shop that I used as a sample is available for download.
  • Walkthrough: MSDN How-To’s on Modeling in 2010
  • Blogs: Cameron Skinner, Peter Provost and last but not least Chris Lovett who has some most awesome video demos and tips for dealing with large diagrams. He also provides some samples for those that are interested in learning more about Directed Graph Markup Language for creating their own diagram generators.
  • The Patterns and Practices Team has released a set of templated layered diagrams for various references architectures.

Visual Studio 2010 At the Movies

Yesterday was the third (or fourth) annual ObjectSharp At The Movies event., For this particular version, we were able to celebrate the launch of Visual Studio 2010 and .NET 4.0 with a plethora of sessions covering VS (naturally) to ASP.NET, Silverlight, Sharepoint and TFS. All in all, it was a successful day that seemed to give the attendees what they came for. The slides that I used for my portion of the talk (which was an overview of VS2010 and .NET 4) can be found here. As always, feel free to ask questions. And, for those that missed it, we plan on doing it again next year. Just don’t know (yet) what the theme will be.

Branching & Merging in 2010

Branching & Merging has always been difficult. I have worked with teams who go out of their way not to branch the code. However sometimes it’s just necessary. Thanks to the Software Engineers at Microsoft it’s much easier now in TFS 2010 Source Control. I don’t mean easier (less key strokes) I mean easier because a Branch is now a first class citizen and there are ways to visualize what change sets have made it into which branches.

Let me show you what I mean.

Lets take a simple application like my calculator and create two branches of the code for the purpose of code promotion. Some source control tools have the concept of a promotion model. Which works kind of like static labels. Code can be promoted from development to QA and Production branches. Dev QA and Production act like labels but there is only ever one Dev, QA and Production promotion level at a time. We can use branching to achieve this. I’m not promoting this method as the way you should promote code, I’m just using it as an example for branching because I think it’s pretty easy to get your head around.

To start I’ll take my Calculator solution and create two branches in source control called QA and Prod. Right click on the project folder in Source control and select Branching and Merging | Branch…

image

On the branch dialog enter the name of the target branch.

image

Create two, one named QA and one named Prod. You will also be asked to create a local folder if you leave the option checked to store it on your local workspace. Don’t forget this operation is a local change and you will have to check in your changes to make it permanent.

Once all is complete you should have the following in Source control.

image

So here we have the Calculator main branch and of course the two promotion branches Prod and QA. Right click on Calculator and select Branching and Merging | View Hierarchy from the popup menu. This will give you a view of the relationships between branches.

image

Right click on the main branch and select Properties from the popup menu. The properties dialog contains information about the branch including relationships to other branches and permissions. This is where you can denote who has the rights to promote to a particular branch.

image

We can use the History View to visualize which branches a changeset has been promoted to. Here are the changesets checked into the my calculator.

image

If you right click on one of the changesets we can see how it has been promoted through the branches. Lets take this bug fix for example. I’ll write click on it and select Track Changeset from the popup menu.

Next we select which branches we want to look at.

image

Click on Visualize to see which branches this Changeset is in. From the Visualizer switch to Timeline Tracking to get this view.

image 

We can see that the changeset has been promoted to both branches. Therefore Changeset 13, 15 and 16 are the same.  Select a changeset and you will see the date and time the changeset was merged into the branch at the top highlights in yellow.

Now try this. Make a change in the base branch then open the visualizer and drag the base branch to one of the other branches this will merge the changeset into the branch you drop it on. Then check in your merge and refresh your visualizer.

Happy Branching and Merging.

Build Process Templates

Making a build script do exactly what you want is easier with 2010?

When setting up a build there has always been a separation of concerns.

  • The Build Definition
  • The Build Process

Creating the build definition is much like you are use to in 2008. Right click on the builds node in the Team Explorer and select New Build Definition. It’s no longer a modal wizard, however it’s the same of information.

  • Name and Description

  • How you want the build to be triggered

  • Working folders

  • Build Server and Drop Location

  • Retention Policy

However there is a big difference, and it relates to the separation of concerns I mentioned above. In 2008 you could create a project file, that you would later have to edit to get the build to do anything extra ordinary. When you hit create on the project file tab you would be launched into another wizard that allowed you to select the solution to build, the type of configuration you wanted to build, weather or not you wanted tests executed against the build and or static code analysis performed.

In 2010 the Process tab contains a type of property grid which allows you to change the configuration of the build. This grid is organized into 3 sections Required, Basic and Advanced, allowing you to specify the solutions to build, define the build number, how to deal with tests and code analysis, weather or not to perform test impact analysis or label the source at this build to name just a few.

Where is all this defined? How would I add extra functionality to my build? What if I wanted to replace a dev.config with a test.config or deploy extra files to the drop location?

At the top of this tab is a show details expander.

image 

After expanding this area you will  be able to select from a list of Build Process Templates.

image

Each template can contain different build processes. Beta2 comes with three templates to get you going. Click New to create your own by selecting a XAML file you have already created a placed in source control, or copy one of the existing templates as a starting point. You will notice also that you can store your Build Template anywhere in source control. In previous versions they only ever existed in one place under source control.

With 2010 you can create a build using the default template, which will likely do most, and more likely all of what you need it to do. In my experience most teams do not customize their project build files so for them the default template will suffice.

If you do want to make changes to your Build process you no longer have to edit a confusing poorly documented XML file. Instead when you open the build template in VS you will be presented with a Windows Workflow editor that allows you to edit your build process template.

image

So why did I start this Blog post with a question? Although it does appear to be easier to add functionality to your build process, For those of us who are Windows Workflow challenged there is some learning to do. The good news is it will be better documented and ultimately easier to find solutions.