Here’s a group photo of many of the Visual Studio ALM MVPs and some Visual Studio Product Group people at the 2010 MVP Summit a few weeks ago.

 
The photo was taken in building 34 on 18 February, 2010.

ASP.NET MVC 2 is a framework for developing highly testable and maintainable Web applications by leveraging the Model-View-Controller (MVC) pattern. The framework encourages developers to maintain a clear separation of concerns among the responsibilities of the application – the UI logic using the view, user-input handling using the controller, and the domain logic using the model. ASP.NET MVC applications are easily testable using techniques such as test-driven development (TDD).

Microsoft released this last Friday. You should go download it and then go learn how to use it.

Microsoft Visual Studio 2010 Professional will launch on April 12. You should secure your copy today by pre-ordering at the (very affordable) estimated retail price of $549, a savings of $250.

If you use a previous version of Visual Studio or any other development tool then you are eligible for this upgrade. Along with all the great new features in Visual Studio 2010, the Professional edition includes a 12-month MSDN Essentials subscription which gives you access to core Microsoft platforms: Windows 7 Ultimate, Windows Server 2008 R2 Enterprise, and Microsoft SQL Server 2008 R2 Datacenter.

So visit the pre-order site to check out all the new features and sign up for this great offer.

I was reading through the new Visual Studio 2010 Licensing White Paper released a couple of weeks ago. It contains a good explanation and examples of multiplexing scenarios. These sounded very familiar, as some of our clients have implemented these in the past. Just to clarify, these scenarios do not reduce the number of TFS CALs that are required, as some people think. End users or devices that accesses TFS in any way, other than the New Work Items (WIWA) exception, are required to have the appropriate licenses, regardless of whether they are using a direct or indirect connection.

What is Multiplexing?
Multiplexing is hardware and software that reduce the number of users or devices that directly access Team Foundation Server. This is also sometimes referred to as pooling.

Example 1
An organization implements an intranet Web site that connects to TFS in a way that enables users to add work items, resolve bugs, or trigger builds through the Web site. Even though only one device (the Web server) is directly connecting to TFS, each person who uses the Web site to access TFS for purposes other than creating new work items must have a CAL or be covered under an External Connector License. (A Device CAL may not be used for the Web server because the Device CAL only supports one user logged-into the specified device at any given time.) A CAL is not required for accessing a second Web site that runs on the same physical Web server but does not access Team Foundation Server.

Example 2
Multiple people simultaneously remote into a server running Terminal Services (or Citrix) to access a development environment. Even though those multiple users are “sharing” one device, each user must have a CAL or be covered under an External Connector License. (A Device CAL may not be used because the Device CAL only supports one user logged-into the specified device at any given time.)

This came up today during a presentation I was giving. I didn’t realize you couldn’t do this from the new Branches in 2010. I did some research and wanted to share my findings.

In TFS 2010 (RC), if you right-click on a regular folder, such as my Code folder:

… your branching options are (Changeset, Date, Label, Latest Version, and Workspace Version):

But, if you convert that folder to the new Branch type in 2010:

… your branching options are reduced to just (Changeset, Date, and Latest Version):

The good news is that you can still use the TF.exe command-line utility to Branch by Label.

I hope Microsoft will address this by RTM (or shortly thereafter), because this begs the question: why convert to branches in the first place? Sure, if you don’t convert to a branch, you’ll be losing a layer of meta-data (owner, description, security permissions, etc.) and semantics, not to mention the slick visualization capabilities (View Branch Hierarchy and Track Changeset), but I’m not sure it outweighs the pain of having to go to the command line to Branch by Label (should that be your thing).

This tool popped-up today during our Scrum Developer trainer-prep in Sydney. One of the teams decided to be over-achievers and delivered their test cases (and results) in a nice Word document format. Turns out they used this Test Scribe tool available on the Visual Studio Gallery. Although in a pre-release version, it worked pretty good and generated some nice-looking

Test Scribe is a tool for generating documentation about TCM (Test Case Management) artifacts. Testers can use a stand-alone client to connect to a TFS 2010 server/project. With a Test Plan selected, users are able to generate a Test Plan Document, including information about the plan, the suite hierarchy, and each test case contained in the suites.

Looks like there might be some issues with using it SxS with VS 2008.

I was flying on US Airways and was reading their January 2010 issue of their free magazine when I came across an article written by Robert Tuchman. It was titled The World Cup: How Sports Unites Us and states something that I’ve always believed: the round ball with the black spots on it is a great cultural barrier neutralizer.

At Accentient, when we deliver classroom training to teams of software developers of mixed nationalities and cultures, we try to keep things as simple as possible, especially when the subject matter is as deep and dry as it is sometimes. Early on I made the decision to use the (soccer) World Cup as my point of reference in our samples, discussions, and activities. Everyone in the room, including the late-to-the-game Americans, understand the references to teams, matches, standings, and statistics. It has served us well.

Go USA!

Microsoft has yet to provide us with some kind of utility to handle the importing, managing, versioning, and deploying of data along with our schema changes inside Visual Studio Team System 2008 database projects. For most of the teams I work with, their needs are simple: they just want the ability to store data (INSERT statements are fine) in scripts within their database projects. Ideally the project would be smart enough to know which version of data goes with which version of schema, but for now they’re able to live with handling that manually.

Here’s one solution, albeit a manual one:

1. Create a database project.
2. Import database schema.
3. Launch SQL Server Management Studio (2008 version).
4. Right-click on the database and select Tasks > Generate Scripts.
5. Select the database and under Script Options deselect everything except for “Script Data”.

6. Click Next and select just the Tables you want (ideally just the smaller, static/lookup tables).

7. Click Next and specify the file to generate – something like LookupTableData.sql and let it rip.
8. You can now take that script and add it to your database project in a folder for data-related scripts.

Ideally you would link in the INSERT script(s) to your Post-Deployment script to automatically populate the data tables upon deployment. You can also use the option in the Generate Scripts dialog to give you one file per table, to maximize your versioning options. If you are already using Data Generation Plans, be careful to not overlap what they are already doing. For more information, be sure to read Barclay Hill’s Part 1 and Part 2 of a posting on how to manage data motion during your deployments.

Until the regular SDK documentation on MSDN is updated for Team Foundation Server 2010, you can find information at its official home on Code Gallery.

You will find the samples for the Team Foundation Server SDK (samples are no longer included with the Visual Studio SDK), deep dive documentation, and links to shared source projects and other resources. This page is maintained by the TFS product team at Microsoft.

Somebody asked me a simple question the other day: “how do I export all of my work items at once”. I suspected they were looking to perform a backup, but it sounded like they might want to import into another system or just archive them in some readable way. I suggested Microsoft Excel, but it can only fetch work items from one team project at a time. So repetition, using a Macro or a human, would be required.

Here’s an alternative we came up with …

1. Downloaded and installed Team Foundation Power Tools.

2. Picked one of the Team Projects, added a query, and removed the Team Project = @Project clause, so that it was completely empty:

3. Changed the Column Options, added the columns we wanted to export. For testing, we selected ID, Team Project, Work Item Type, and Title.

4. Ran the query and verified that it pulled the right work items and fields we wanted.

5. Saved the query (My query) and named it AllProjectWorkItems.

6. Dropped to the command prompt and executed the following commands:

    cd c:\Program Files\Microsoft Team Foundation Server 2008 Power Tools

    tfpt query "Calculator\My Queries\AllProjectWorkItems" /Server:vsts /format:xml > c:\AllWorkItems.xml

7. This command generated an XML file containing all of the fields from all work items from all projects. This satisfied their requirement.

At this point you can update the query adding more columns, until you have the superset of what you need for the export of all types from all projects. With a little finesse, the XML document could be migrated into Excel or another software application.

Out of the box, Microsoft has a Work Items check-in policy which requires you to select at least one work item when checking in your code in TFS 2008. If you install the Team Foundation Server Power Tools, you’ll get the Work Item Query check-in policy. This is nice because it allows you to specify a team query to which the work item associated with a check-in must belong. The example I give is that the team may want to spend the next couple of days on a “bug bash”, so you could use this policy to point to the “Active Bugs” query, etc.

What’s missing is a policy that enforces you selecting exactly one work item during check-in. I believe this is crucial for maximum traceability: one changeset to one work item. This is a good habit to adopt as it increases the maintainability of the code, offering better get, branch, build, and merge options. Another way to put it: chatty check-ins (many, throughout the day) are preferred to chunky check-ins (one big one at 5pm).

If only Microsoft had added a configuration page to either of the above policies, I wouldn’t have had to build this policy.

Follow the P&P How-To guidance using the attached project to implement this policy.

Attachments: SingleWorkItemPolicy.zip (19kb)