Skinner's Blog : VSTS 2010 Fall CTP

Channel 9 and 10-4

camerons — Thu, 18 Dec 2008 06:09:51 GMT

If you are not already aware of Channel 9, stop what you are doing right now and go check it out.

Really.

I'll wait. :)

Channel 9 has a long a brilliant history of shining a light on all things that Microsoft is doing through the video medium. Soon after the 2008 PDC was over, the session videos were made available on Channel 9, allowing folks who couldn't make the conference to see the details, but also giving the folks who were there the ability to catch the sessions they were unable to catch in person. ( Here's the link to my talk at the PDC. )

In addition, when the VSTS 2010 CTP became available, the Channel 9 folks launched a series of videos that introduced you to the various areas of the Team System product line ( including your's truly :) ).

Well now, they're doing it again.

Today the Channel 9 folks have announced a new video podcast series entitled "10-4". The idea is simple: every week, provide a video to the community detailing various aspects of Visual Studio 2010 and the .NET Framework 4.0.

Check out Brian Keller's post for some more details.

I love those guys!

"Standard Graphs"

camerons — Thu, 18 Dec 2008 03:04:47 GMT

It became clear from the emails and comments to my last post that I should probably spend a little more time describing the functionality found in the VSTS 2010 CTP a bit better, specifically that functionality involving the Architecture Explorer and the graphs generated via the AE. ( I just figured everyone had already run out, downloaded that 7.5gig image, and started playing! :) )

This post introduces the three "Standard Graphs" found off the Architecture Explorer using the DinnerNow - ServicePortfolio2 solution found in that aforementioned CTP. The idea behind these graphs are to give you the ability to get some "typical" views of your source base with as few mouse clicks as possible.

Standard Graphs

Here's a shot of the Archicture Explorer, as seen with the DinnerNow solution open in VS 2010:

You'll notice the Visualize Code Relationships menu item, which is where you'll find the three menu items that will create graphs by Assembly, Namespace, or Class dependencies based on the contents of the current solution.

Visualize Call Dependency - By Assembly

If you select the Visualize Call Dependency - By Assembly menu item, here's what you'll get:

This graph is all about showing you the dependencies between the various assemblies that make up all the projects in your solution. If you don't have the solution built, you'll notice that after selecting this menu item ( this will happen for any "standard" graph actually ) the solution is built. This is due to the fact that we are cracking the assemblies in the output directories and gathering the information found there.

The nodes you see above represent each of the assemblies discovered in this solution. You'll also notice links of various thickness between these nodes. The thicker the link, the more dependencies between the two assemblies. We sometimes refer to these types of links as "blood vessels".

Notice the chevrons in the upper right hand corner of the nodes in this graph:

This is an "expand / collapse" button for this "group" node. You'll also notice in the upper left corner of each node, a number indicating the number of internal nodes inside the group. Here's what the DinnerNow.Services assembly node looks like when expanded ( click for larger view ):

The green and blue nodes represent Classes and Interfaces. You'll notice in the shot above the tooltip displayed as I hover over the CustomerService node, the category reads "Class". If I double-click on that node, it takes me to the source code where that class is defined.

Visualize Call Dependency - By Namespace

Selecting the Visualize Call Dependency - By Namespace results in a similar type graph, except this time the initial nodes you see below represent the namespaces found in the solution:

Clicking on the chevron of the DinnerNow.Services node shows the exact same information as it did when viewing from the Assembly diagram ( show below in-situ ):

Visualize Call Dependency - By Class

Selecting the Visualize Call Dependency - By Class results in the most complicated of graphs, mostly because what you are seeing is dependencies at the class level, with no grouping by assembly or namespace. Expanding a chevron in this graph reveals methods, properties, fields, indexers, etc. that are contained by that class or interface. Below is a shot of just a section, as the graph is pretty large:

One thing to point out if you haven't already discovered this, is that if you hover your mouse over a particular link, you can quickly jump to either end of the link. Quite helpful on large graphs like the Class dependency graph!

One other thing worth mentioning. The dependencies discovered on these graphs are dependencies discovered through static analysis of method call data, not structural dependencies. For example, if you have two classes that don't call each other but one includes the other as a type for a member, no dependency link will be created.

What other "Standard Graphs" should we include out of the box? What are some typical views over your solution that you would like one to two clicks away?

Thanks!

Cameron

Introduction to Directed Graph Markup Language ( DGML )

camerons — Tue, 16 Dec 2008 23:59:53 GMT

DGML, or "Directed Graph Markup Language" is what we are using in VSTS 2010 Architecture to render graphs like the one below:

The power of DGML is in its simplicity. Let me show you what I mean.

If you launch the VSTS 2010 CTP, open a project, click View->Architecture Explorer, then click the button shown below...

...you'll get a new dgml editor in the document well. You can then right click inside that document and select "View Code". Right click on the tab of the resulting editor and select "New Horizontal Tab Group". You'll have something similar to this:

If you add a Link element as a child element to the Links node, with a Source and Target attribute, you'll get something similar to this:

To add a few more elements, try this:

You'll notice the Nodes element isn't even needed to render the graph above. That is really all you need to know to visualize all kinds of data. Rest assured there is a lot more goodness to discuss about this technology, but the simplicity of it is one of the most exciting aspects as far as I'm concerned!

In my next post, I'm actually going to show you how, armed with just this little nugget of DGML information, you can visualize some Java code. Stay tuned!

Incorporate Layer Validation in your Builds

camerons — Thu, 11 Dec 2008 08:20:27 GMT

As I promised in my last post, I want to show you how you can make Layer Validation part of your build process. I'm going to assume you've followed along from last post to make things easy. Again, this is all possible in the VSTS 2010 CTP.

Unload the "Client" project ( Right click on the "Client" project and select "Unload Project" )
Once unloaded, right click on the unloaded "Client" project and select "Edit Client.csproj":
Find this line:

<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />

And add this line right after it:

<Import Project=" $(ProgramFiles)\Microsoft Visual Studio 10.0\Team Tools\Architecture Tools\Microsoft.VisualStudio.TeamArchitect.Validate.Targets"/>

This is a temporary step to make this work in the CTP. At RTM ( and even for Beta ), the new targets file will be part of the core MSBuild targets file.
Save the project, then reload.
You'll be presented with this dialog:
Click on the "Load project normally" and click OK.
Now drag the "FirstLayerDiagram.layer" file from the "Diagrams" solution folder into the "Client" project.
Delete the "FirstLayerDiagram.layer" file from the solution folder.
Select the "FirstLayerdiagram.layer" file that is now in the "Client" project, and set its "Build" action to "Validate":

Now if you did want to leave the "FirstLayerDiagram.layer" file in the "Diagrams" solution folder, you would have to manually edit the "Client.csproj" file, changing this line:

<Validate Include="FirstLayerDiagram.layer" />

to this:

<Validate Include="..\FirstLayerDiagram.layer" />

You're project would look something like this ( notice the little arrow overlay, indicating that this is a reference to a file elsewhere ):
Now at this point you could drop to the command line, assuming the Client.csproj file is in "c:\temp\Layer Validation\Client", and type "msbuild /t:ValidateArchitecture".

Ideally, it would be great to incorporate this step into the build process whenever you build the solution or Client project. You would do something like add a DependsOn="ValidateArchitecture" attribute to the "AfterBuild" target in the project file. Unfortunately, the same bug that requires you to refresh the Architectural Explorer after each build of the project will prevent this from working as it should. Clearly, this will be corrected by RTM.

Hope that helps!

Cameron

Layer Validation with the VSTS 2010 CTP

camerons — Tue, 09 Dec 2008 08:26:25 GMT

In my first post of this series, I broke down the VSTS 2010 Architecture product into "functional" areas, and I've been slowly describing the pieces. The areas highlighted ( Modeling Project here and here, Model Explorer, and Work Item Integration ) I've already discussed at some length. Today, I want to drill into the Layer Diagram a bit more. Specifically, I want to walk you through the steps of creating a simple Layer diagram, map your code onto it, and validate that code against the constraints authored in the diagram via a manual validation gesture. ( In a future post I'll show you how to automate validation in your build process. )

For this post, I'll be using the VSTS 2010 CTP.

In this example, I'm going to be using some very simplistic code, as it is not the details of the code that I'm trying to emphasize, but more the concept the code represents. Let's get started...

Start you VSTS 2010 CTP image
Launch VS 2010
Create a C# console app called "Client", and name the solution "Layer Validation". You're "New Project" dialog should look similar to this:
Now right click on the solution node, select "New Project...", select "Class Library" and name the Project "Implementation":
Do the exact same thing you just did in step 4, except name the project "Interfaces".
Again, do the exact same thing except name the project "Creators". You should have a solution explorer that looks similar to this:
Now expand the "Interfaces" project node. Right click on the "Class1.cs" file, select "Rename", rename the class to IDataRetriever.cs, and click the "Yes" button when prompted. You should now see something like this in your document well and Solution Explorer:
Change IDataRetriever into an interface by replacing the "class" keyword with "interface".
Now add a getter property that returns an object that implements the "IData" interface. You'll notice that VS is indicating to you that IData doesn't exist yet by putting the red squiggles underneath "IData":

Let's resolve this error by taking advantage of a new feature in VS 2010.
Right click on the offending "IData", select "Generate", and select "Other...":
You'll now be presented with the "New Type" dialog. Change the "Type Kind:" drop-down to "interface" and the "Access:" drop-down to "public". Leave the rest as defaults:

VS will automatically create a new interface called "IData" in a new file called "IData.cs" placed in the Interfaces project. Nice, that's exactly what we wanted! Now let's go implement the IDataRetriever interface over in the "Implementation" project.
Expand the "Implementation" project node.
Right click on the "References" node, select "Add Reference...", click the "Projects" tab, and select "Interfaces":
Collapse the "References" node.
Right click on the "Class1.cs" file, select "Rename", change the file name to "DataRetriever.cs", and select "Yes" in the dialog that pops up.
Double-click on the "DataRetriever.cs" file, and make the new class implement the "IDataRetriever" interface. You'll notice that as you attempt to type "IDataRetriever", you get no intellisense support. That's ok, finish typing in "IDataRetriever", and again notice the red squigglies below the term.
Hover over "IDataRetriever" and notice a small rectangle under the start of the word. Click on that and select "using interfaces;". This will automatically insert the using statement that is required.
Now that the "using Interfaces;" line has been automatically added, select the "smart tag" again, but this time select "Implement interface 'IDataRetriever'":

Your final "DataRetriever" file should look like this:
Now add a reference to the "Implementation" project as well as the "Interfaces" project, following the similar steps in step 13 above.
Expand the "Client" project node and double click on "Program.cs".
Type "DataRetriever", select the smart-tag and select "using Implementation;". That will automatically generate the using statement needed to use the DataRetriever type. Finish like so, adding the "using Interfaces;" statement as well:
Rebuild the solution. If all went according to plan, no errors.

So what does this program do at this point? Well, actually nothing except instantiate a type, call a property on that type, throw a "NotImplementedException", then exit. Not that interesting, but also not the point. This is just setting the stage for a very common problem found in systems of all types.

This code is pretty typical of code that is early in its evolutionary path. We've got a client program accessing the specific implementation of an interface directly. This is fine for now, as all the program needs is the data that "DataRetriever" was designed to retrieve ( imagine DataRetriever pulling from a SQL database for instance ). But what about tomorrow when a requirement hits your desk, demanding data to be pulled from a different data source without changing the behavior of the rest of the application?

What we need is to *not* make any assumptions on *how* an interface is implemented, and depend *only* on the contract of the interface(s) itself. Again, a fairly common design pattern, but one that is pretty easy to violate in today's world, as it takes but one line of code to break this pattern and create dependencies that were not intended. This is what various IoC containers are out to help mitigate.

So how do we enforce this design in our code, protecting the intent of that design, and ensure our code is resilient to this type of breakage? Enter the Layer Diagram and Layer Validation.

Let's create a Layer Diagram where we will visually describe the constraints on our architecture that we want to maintain.

Create the Layer Diagram

Right click on the solution node and select Add->New Solution Folder. Name the folder "Diagrams"
Right click on the "Diagrams" solution folder and select Add->New Item..., select the "Layer Diagram" template, and name the diagram "FirstLayerDiagram.layer":
Since these are CTP bits, there are still a few things not quite right. One of these things is the fact that you'll see two Layer Diagram Explorers appear next to your Solution Explorer. Close the one that looks like this:
Now let's draw the layer diagram, make your diagram look like this one:

Please make sure that the links are going in the direction you see above, or things aren't going to work right in later steps!

What we're saying through this diagram is that we have a "Client Logic" layer that is dependent on the "Interfaces" layer, and an "Implementation" layer also dependent on the "Interfaces" layer. What we are also saying is that the "Client Logic" layer is *not* dependent on the "Implementation" layer, nor should it be. The lack of a directed link in this last case is very important.

But now we need to map our source code onto this layer diagram, so that the system can verify that your code is complying or *not* complying with the constraints this seemingly simple diagram is describing.

Let's do that now.

Map Source Onto the Layers

In the Solution Explorer, click and drag the "Client" project out onto the layer diagram and release your mouse on the "Client Logic" layer shape:
Drag the "Interfaces" project from the Solution Explorer out onto the layer diagram and let go over the top of the "Interfaces" layer shape:
And finally, drag the "Implementation" project from the Solution Explorer out onto the "Implementation" layer shape:
Your layer diagram should now look something like this. Notice the little icons in the upper right hand corner of the shapes. This indicates that source ( or some type of artifact(s) ) has been associated to the layer:

If you select the "Client Logic" shape, then click on the "Layer Explorer", that shows you the types of items associated with the layer. In this case, the "Client" csharp project:

Now we're ready to "Validate" our code against the diagram.
Right click anywhere in the layer diagram and select "Validate":

Notice an error is displayed in the Error Window:

This is expected at this point, 'cause the code in Program.cs found in the "Client" project is directly manipulating types from the "Implementation" project. We just finished creating a layer diagram that declares this type of dependency invalid!

So let's fix the problem in code so that this layer validation error goes away.

Fix Code

Back in Program.cs, we need to make sure that we are only using types out of the "Interfaces" project, or more importantly, *not* use types out of the "Implementation" project. That's all well and good, but we need a way to get an instance of an object that implements IDataRetriever without taking a direct dependency on that type.

Enter the Factory pattern.

In the Solution Explorer, expand the "Creators" project, right click on "Class1.cs", select "Rename...", and rename the file to "TypeCreator.cs".
Add the "Implementation" project and "Interfaces" as a references to the "Creators" project ( i.e., "Creators" now depends on the "Implementation" and "Interfaces" projects ).
Double click on the "TypeCreator.cs" file in Solution Explorer, which will make that file fill the document well.
Add a static method that creates a "DataRetriever" object but returns an IDataRetriever interface. TypeCreator.cs should look similar to this:
In the "Client" project, remove the "Implementation" project reference, and add a reference to the "Creators" project.
Change Program.cs to take advantage of the new method we just created. Program.cs should look something like this:
Rebuild the solution. No errors.

Now we need to bring up the Architecture Explorer and click the refresh button to work around a current limitation in the CTP bits.
From the main menu bar, select "View->Architecture Explorer".
Select the "Refresh Content" button on that explorer:
Now bring the FirstLayerDiagram back into view, right click on "Validate", and take a look at the error tool window. No errors! WooHoo! :)

Summary

I've shown you, through an admittedly trivial example, how to validate your solution through a simple Layer diagram. I've shown you how to map source onto the layers and how to tell the system what dependencies are valid and which are not via a manual gesture and that diagram.

There is much more to show on this diagram and how you can interact with it. A very important next step is to show you how to make the Validation action an automatic step in your build process. I'll do that in a future post.

Stay tuned! :)

Cameron

VSTS 2010 CTP, Hyper-V, and January 1st, 2009

camerons — Sun, 07 Dec 2008 00:40:48 GMT

For those of you folks who have converted the VSTS 2010 CTP ( see Grant's post ) to take advantage of the performance improvements in hyper-v, here's a manual way to get around the fact that VSTS will expire Jan. 1st 2009. ( If you're using the CTP with VPC, see Brian's post for a similar workaround ).

1) The first thing to do is snapshot your current image ( if you followed Grant's steps, that should have been the last thing you did while you converted your image to hyper-v ). You'll need this to rollback as needed.

2) Next, you need to turn off the Time Synchronization feature that the Integration Services of Hyper-v do for you. Do this by going into your Hyper-V Manager, right click on your VSTS 2010 CTP image, select "Settings...". This will prevent the guest image from automatically synching its system time with the host machine while the guest is running. If you don't do this first, steps 4+ won't work at all.

3) Now start the CTP image.

4) In the bottom right hand corner of the CTP image, click on the time display in the status bar, which brings up the clock settings. Click "Change date and time settings..."

5) In the "Date and Time" dialog, click on the "Internet Time" tab, click the "Change settings..." button, which gives you the dialog below. Uncheck the "Synchronize with an Internet time server" check box. Hit OK.

6) Now back in the "Date and Time" dialog, change the date to something like October 20th, 2008 by first clicking on "Change date and time..." button. You can't go back too far, otherwise you'll get the dreaded "Eval has expired" dialog. Hit OK on that dialog, and then OK again to close the "Date and Time" dialog.

7) Now fire up VSTS, you're good to go!

Since this is such a manual process, I would recommend going through the steps above, and then Pause then Save the image each time you want to regain the memory being used up by the image.

Hope that helps,

Cameron