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.

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)

If you’re like me, then you don’t pay attention when you install a lot of software. Often times I just click Next > Next > Finish without reading the screens.

For example, I guess I wasn’t paying attention to who the registered user was when I installed Visual Studio 2008 or Windows for that matter, because the splash screen shows this:

Yes, it’s a registry setting and you can find/set it here:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\RegisteredOwner

Unfortunately, changing it didn’t do anything, until I learned the trick from John Robbins (Wintellect):

After you change HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\RegisteredOwner, restart Windows and then run “DEVENV /setup” from an elevated PowerShell window. That will update the splash screen registry key.

I was at a client site last month where they have TFS2008SP1 installed and running on Windows Server 2008 SP1. Everything was working fine. We created several team projects. No problems.

I come back three weeks later and it wouldn’t create a team project. I kept getting the “Project Creation Wizard encountered a problem while uploading documents to the Windows SharePoint Services server” error. According to the client, they hadn’t touched anything. So, I started with Ben Day’s blog post on the subject, but his fix didn’t work for me. I then checked all the service accounts, permissions, farm administrator group, database status, etc. – all the standard things, but no help.

Come to find out none of the SharePoint collection/sites would come up, let alone allow me to create new ones. The Admin site worked, but every other site gave the “Cannot complete this action. Please try again” wonderfully helpful error message.

Windows event logs and SharePoint event logs were useless, but I did find a KB article talking about setting impersonation explicitly from code, so I decided to check the Authentication settings on the Default Web Site and sure enough it was Disabled. I changed it to Enabled, ran IISRESET for good measure, and voila!

I watch House enough to know that “everybody lies”. It’s a basic Houseism. That was the case here. The “we didn’t touch anything” statement turned out to be false.

As I was explaining how the Build > Deploy process is radically different this week, a question came up about licensing restrictions around the vsdbcmd.exe command-line utility that ships with the GDR. Here’s a quick history lesson:

The Pre-GDR Way

The Build process analyzes the target connection and then assembles all of the various .sql scripts into one large .sql script. The resulting script would contain CREATE or ALTER statements depending on what it found when it studied the target connection. The script also contains other custom scripts and variables you want to define. The problem is that this Build process requires access to that target environment. This was not always a possibility – either the developers didn’t have permissions, or ISVs didn’t have physical access to their customer’s datacenters. Finally, the Deploy process would then just execute the big .sql script against the target connection, which could be done using VS, SSMS, SQLCMD, etc.

The GDR Way

The Build process generates a .dbschema file which represents the current schema definitions of the database project in a single, easy-to-handoff XML document. This document has accompanying scripts and manifest files as well. The Deploy process then creates the .sql script and (optionally) executes it. The Deploy is now the only connected operation and it can be performed from Visual Studio or by using the new vsdbcmd.exe command-line utility. The major difference is that Build doesn’t need access to the target database, only Deploy does. This rocks, because now you can just give the .dbschema file to that department’s DBA or that customer’s datacenter admin, etc. and only they need access to the target to generate the proper script and to execute it. Problem solved.

… but question raised: what about the licensing of the vsdbcmd.exe file? Can the developer or ISV just give it to their respective user to deploy the changes?

The answer (thanks to Ted Malone, SQL guru and VSTS MVP) is YES, as explained in this article by Gert Drapers.

BTW - GDR R2 is available so you should download it now!

There has been a vacuum of really good, actionable information on MS Build and Team Foundation Build for developers. I’m pleased to report that this is no longer the case! Inside the Microsoft Build Engine, by Sayed Ibrahim Hashimi and William Bartholomew, fills the void with a book that serves well as both a learning guide and a reference tool. Here’s the product description:

"The build process when code gets assembled to see how and how well it works is a critical step in software development. Developers had few options for customizing the build process before Visual Studio 2005 and Visual Studio 2008, but the Microsoft Build Engine (MSBuild) enables developers to customize each step during a build. MSBuild is extensible and uses an XML file to describe each step, allowing the build master or developer to easily change and augment how projects are built. This book offers hands-on guidance for customizing MSBuild, and provides a cookbook of examples on Web deployment, automated releases, and other essential topics. It also covers Visual Studio Team Foundation Build, the build engine in Visual Studio Team System."

If you have anything to do with automated builds using Team Foundation Server, this book is a must-have. I know this for a fact because I had the opportunity to serve as a technical reviewer for the book.

Some Team System users are complaining about problems with the Team Members feature included in the Team Foundation Server Power Tools – October 2008 Release. For team projects with many members, the load time can be excessive. Other problems have cropped up as well. For instance, one user reported that their Windows Communicator freezes during long TFS operations like “get latest”. Although the Team Members plug-in has some very useful features, you may find that it’s more trouble than it’s worth for your particular situation. In this case, you have two options:

Option 1: Disable the Team Members feature. In the Visual Studio, navigate to Tools –> Options –> Team Foundation Server Power Tools –> General, then set Team Members to False.

This does not remove the Team Members node from your team projects in Team Explorer, but the node no longer does anything. Also, some of the Team Members start-up logic still executes. If this continues to cause problems for you, then try this more drastic fix:

Option 2: Registry hack. This is a more complete way of disabling the TeamMembers feature, but it cannot be done in the Visual Studio IDE.  Using the RegEdit utility, navigate to:

HKCU\Software\Microsoft\VisualStudio\9.0\TeamFoundation\PowerTools

Add a new String Value named TeamTrackerHidden and set its value to True. 

This setting tells the Team Explorer to not load the Team Members plug-in.  This will cause the Team Members node to appear as a folder with a red X on it, which is mildly annoying. However, this option will definitely eliminate any issues you’re having with the Team Members feature.

(Thanks to Bill Essary @ Microsoft for providing these work-arounds)

Recently I was working with a client who installed the Team Foundation Client 2008 on his workstation, and subsequently decided to install Visual Studio 2008 Development Edition. The installation completed normally, but when he launched Visual Studio he quickly discovered that some important things were missing.

For instance, the File menu was missing the New Project item. It was as if the we were still looking at the Team Foundation Client, and that the installation of the Development Edition had somehow failed. At first this was very puzzling until a sharp developer suggested that we look at the Settings (Tools –> Import and Export Settings)

Sure enough, Team Foundation Client had installed and automatically selected the setting called Project Management. Although the Development Edition installation added a few more settings, it left the selection unchanged. Once we changed the selection to something more appropriate, all the normal menus became visible. Mystery solved!

I finally took the time to put together a chart showing which edition of Visual Studio needs to be installed on the Team Build server to achieve specific features. As you can see, Team Suite has you covered. As for the question of whether or not you need to purchase an additional copy of Visual Studio for this - that question has been answered on Jeff Beehler's blog as well as in the VSTS 2008 Licensing White Paper.

I might also add that Brian Randall mentioned that you can automate the validation of Architect Edition Deployment Diagrams on the Team Build server if you install that edition; but, being that he's the only guy on the planet to probably do that, I didn't think it was worth mentioning.

Team_Build_Target_Map1.docx (22.73 KB)

I had the good fortune of reviewing the upcoming book titled Inside the Microsoft® Build Engine: Using MSBuild and Team Foundation Build. This book is an absolute must for anyone who is creating and customizing build definitions in Team Foundation Build. As part of my review process I created a map that lists the order of target invocation. I found this map very handy, so I’m posting it because I figure others will find it handy too. The map is listed below, and also contained in the attached word document. If you make any corrections or improvements to the map, please share back!

By the way, MSBuild Sidekick turned out to be very useful in building this map. The Team Foundation Build targets file is large and complex. MSBuild Sidekick's tree-view makes it much easier to navigate this beast, and the search features made it easy to traverse the target dependencies. This is a very handy tool for editing (or studying) build scripts.

This map shows the order of target execution in the Team Build targets file,  %ProgramFiles%\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets. The target names in the map are color coded as follows:

Green: this is an extensibility target that can be customized in your TFSBuild.proj file
Blue: This is run as a separate MSBuild process to support parallel processing

EndToEndIteration

When a Team Build agent starts a new build, the build starts by invoking the EndToEndIteration target. This target then invokes the following chain of targets.

·         CheckSettingsForEndToEndIteration

·         InitializeBuildProperties

·         BeforeEndToEndIteration

·         BuildNumberOverrideTarget

·         InitializeEndToEndIteration

·         InitializeWorkspace

o   BeforeInitializeWorkspace

o   CoreInitializeWorkspace

o   AfterInitializeWorkspace

·         TeamBuild

o   CleanAll (CleanCompilationOutputOnly != true)

o   InitializeBuild

o   PreBuild

§  Get

·         BeforeGet

·         CoreGet (SkipGet != true)

·         AfterGet

§  Label

·         BeforeLabel

·         CoreLabel (SkipLabel != true)

·         AfterLabel

o   CleanCompilationOutput (CleanCompilationOutputOnly == true)

§  BeforeClean

§   CallClean (SkipClean != true)

·         CoreCleanCompilationOutput

o   ComputeConfigurationList

o   CleanConfiguration

§  BeforeCleanConfiguration

§  CoreCleanConfiguration

·         ComputeSolutionList

·         CleanSolution

§  AfterCleanConfiguration

§   AfterClean

o   Compile

§  BeforeCompile

§  CallCompile

·         CoreCompile

o   CompileConfiguration

§  BeforeCompileConfiguration

§   CoreCompileConfiguration

·         ComputeSolutionList

·         CompileSolution

o   BeforeCompileSolution

o    CoreCompileSolution

o    AfterCompileSolution

§   AfterCompileConfiguration

§   AfterCompile

o   PostBuild (SkipPostBuild != true)

§  GetChangesetsAndUpdateWorkItems

·         BeforeGetChangesetsAndUpdateWorkItems

·          CoreGetChangesetsAndUpdateWorkItems (SkipGetChangesetsAndUpdateWorkItems != true)

·          AfterGetChangesetsAndUpdateWorkItems

o   Test

§  BeforeTest

§   CoreTest

·         RunTest

o   TestConfiguration

§  BeforeTestConfiguration

§   CoreTestConfiguration

·         ResolveTestFilesForEndToEndIteration

§   AfterTestConfiguration

§   AfterTest

o   GenerateDocumentation

o   PackageBinaries

·         DropBuild

o   BeforeDropBuild

o    CoreDropBuild (SkipDropBuild != true)

o    AfterDropBuild

·         AfterEndToEndIteration

DesktopBuild

This is the target execution sequence when you perform a Desktop Build. For more information on configuring and using a Destop Build, see this MSDN article.

·         Compile

o   BeforeCompile

o   CallCompile

§  CoreCompile

·         CompileConfiguration

o   BeforeCompileConfiguration

o    CoreCompileConfiguration

§  ComputeSolutionList

§  CompileSolution

·         BeforeCompileSolution

·          CoreCompileSolution

·          AfterCompileSolution

o    AfterCompileConfiguration

o    AfterCompile

·          Test

o   BeforeTest

o    CoreTest

§  RunTest

·         TestConfiguration

o   BeforeTestConfiguration

o    CoreTestConfiguration

o   AfterTestConfiguration

o    AfterTest

·          GenerateDocumentation

·          PackageBinaries

DesktopRebuild

Start a build using DesktopRebuild as the initial target to perform a clean, full compilation and run tests.  For more information on how to build team projects on the desktop, see this MSDN article.

·         Clean

o   BeforeClean

o   CoreClean

·         CoreCleanAll (CleanCompilationOutput != true AND SkipClean != true)

·         CallClean (CleanCompilationOutput == true AND SkipClean != true)

o   CoreCleanCompilationOutput

§  ComputeConfigurationList

§  CleanConfiguration

·         BeforeCleanConfiguration

·         CoreCleanConfiguration

o   ComputeSolutionList

o   CleanSolution

·         AfterCleanConfiguration

o   AfterClean

·         DesktopRebuild (see previous section for details)

OnBuildBreak

If an error occurs during the compile phase, normal processing is suspended and the OnBuildBreak target is invoked. This target then invokes the following sequence of targets:

·         BeforeOnBuildBreak

·          CoreOnBuildBreak

o   GetChangesetsOnBuildBreak

§  BeforeGetChangesetsOnBuildBreak

§   CoreGetChangesetsOnBuildBreak (SkipGetChangesetsAndUpdateWorkItems != true)

§   AfterGetChangesetsOnBuildBreak

o   DropBuild

§  BeforeDropBuild

§   CoreDropBuild

§   AfterDropBuild

o   CreateWorkItem

§  BeforeCreateWorkItem

§  CoreCreateWorkItem (SkipWorkItemCreation != true)

§  AfterCreateWorkItem

·         AfterOnBuildBreak

Skip Properties

These properties are used to suppress the execution of certain targets in the build sequence.  A complete list of customizable Team Foundation Build properties can be found in this MSDN article.

·         SkipClean

·         SkipDropBuild

·         SkipGet

·         SkipGetChangesetsAndUpdateWorkItems

·         SkipInitializeWorkspace

·         SkipInvalidConfigurations

·         SkipLabel

·         SkipPostBuild

·         SkipWorkItemCreation

At a client site this week, and having to generate the same initial folder structure for many team projects, so I thought I would create a script (.BAT file, no PowerShell sorry).

Below is the script, but here are a few details to point out:

• I assume that my workspace name and local folder name is the same as the team project
• I put my local workspace folders under a common D:\Workspaces folder
• You can set the team project name easily by tweaking the SET line below
• I could have, and should have parameterized the folder root, TFS, comments, etc.

Hope you can make use of it:

@ECHO OFF

SET TeamProject=Sample

ECHO Create folder Structure
ECHO.

D:
CD\
MD D:\Workspaces
MD "D:\Workspaces\%TeamProject%"
MD "D:\Workspaces\%TeamProject%\Code"
MD "D:\Workspaces\%TeamProject%\Code\DEV"
MD "D:\Workspaces\%TeamProject%\Code\QA"
MD "D:\Workspaces\%TeamProject%\Code\PROD"
MD "D:\Workspaces\%TeamProject%\Documents"
CD "\Workspaces\%TeamProject%"

ECHO.
ECHO Drop existing workspace
ECHO.

"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\TF.EXE" workspace /delete /noprompt /server:TFSSRV1 "%TeamProject%"

ECHO.
ECHO Create workspace mapping
ECHO.

"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\TF.EXE" workspace /new /noprompt /computer:TFSSRV1 /comment:"Created by Richard Hundhausen" /server:TFSSRV1 "%TeamProject%"
"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\TF.EXE" workfold /server:TFSSRV1 /workspace:"%TeamProject%" /unmap $/
"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\TF.EXE" workfold /server:TFSSRV1 /workspace:"%TeamProject%" /map $/"%TeamProject%" D:\Workspaces\"%TeamProject%"

ECHO.
ECHO Adding folders to version control
ECHO.

"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\TF.EXE" add Code /recursive /noprompt
"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\TF.EXE" add Documents /recursive /noprompt

ECHO.
ECHO Check in
ECHO.

"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\TF.EXE" checkin /comment:"Created by Richard Hundhausen" /noprompt /recursive "D:/Workspaces/%TeamProject%"

PAUSE

As you know, Visual Studio 2008 and Team Foundation Server 2008 Service Pack 1 was released earlier this month. Most of SP1 was about bug fixes and performance, but it seems that the profiler team snuck in several new features as well:

• Adding support for instrumenting 64-bit managed C++ applications
• Improved instrumentation experience with pre-compiled web sites
• Shipping the 64-bit performance SDK (VSPerf.h, VSPerf.lib)
• Ability to load a previously saved filter on non-English VS installations

Here is a link to the VS2008SP1 readme and a page listing all of the SP1 downloads.

My final talk at VSLive! San Francisco this week was on one of my favorite topics - parallel development. In other words, dealing with the real-world situations where multiple developers are coding away on the same project, and even the same file.

The first order of business was to have a few of the ex-Visual SourceSafers lay down on my couch so we could discuss their phobias and irrational urge to run to their "safe place" - a.k.a. locking.

In all seriousness, we discussed the two locking models of TFS and then explored the many wonderful benefits of not using locks by default, known as shared check out. Most in the audience agreed that the benefits of not blocking each other with their routine development (for example, not locking .csproj files when somebody adds a new file) greatly outweighs the detriment of having to deal with a conflict that requires manual intervention. Of course, arguments can be made either way.

I pointed out that there are four situations where conflicts can occur that may require auto/manual merging:

• CHECK-IN - the most obvious; somebody else may have just checked in competing changes just before you
• GET - you may already have pending changes on one or more of the files you are trying to download
• MERGE - by definition; when you merge changes from one branch to another, the chances are good that you will have to resolve conflicts
• UNSHELVE - not so obvious, but this is basically like a GET, just coming from another location in TFS; unfortunately, Team Explorer doesn't know how to handle the detection/resolving of these types of conflicts, so look to the TFPT UNSHELVE power tool for help

Finally, we looked at setting up a source control folder structure that will support your teams promotion model (a.k.a. staging environment). I proposed a simple structure, that looks somewhat like this:

Some explanations

• Code holds code artifacts - C#, VB, SQL, WiX, etc.
• Documents holds snapshots of the SharePoint site archived at the end of each iteration, release/version, build, etc. (whatever your term is)
• Active development occurs in "Current", which you could name "Dev" or "Main" (although I prefer "Main" for integration)
• Under the "Current" folder you'll have folders for each high-level application/component in the system, including common, database scripts, build definitions, and even setup projects
• "Branches" are just that - QA, UA, RC, Release, and private branches (Bridges), etc.

If you'd like to have a look at my slide deck, you can find it here.

That was the topic of our discussion today at VSLive! San Francisco. Unfortunately, in the short amount of time (75 minutes) we didn't get too deep into all of the tools and techniques, but I did get my point across: I feel that Team Foundation Server (TFS) can do it all, and you should strive to migrate your source/revision control system, requirements and defect tracking system, document managing system, automated build and deployment system, and even your custom process workflow over to TFS.

That said, there are certainly situations where existing systems must be used. I identified two categories of such legacy software:

• Politicalware - somebody important in the organization bought or built the system and you there are strong feelings about migrating away from it
• Guiltware - the organization spends oodles (that's a lot) of cash on said software, maintenance/support, training, etc. and they haven't seen their ROI (and they may never see it)

I don't know what to tell you about the above situations, except that running in parallel (not good) or integration (better) would be an option. That lead us to the discussion of building custom software to do one-way and two-way synchronization with said systems. We briefly walked through the TFS Migration and Synchronization Toolkit (found on CodePlex) and I demonstrated the TFS to TFS Migration Tool (also found on CodePlex) which uses the toolkit.

I see Team Foundation Server as yet another great "grassroots" platform. Just like .NET was for the developers, TFS is for the team. So, I say get it installed no matter what, even if just for source control, which is the no-brainer. Once it's in-house, then work on migrating the work items, automated builds, and other systems over sooner, rather than later, so you can enjoy the end-to-end traceability, product quality reports, and process quality reports.

If you'd like to have a look at my slide deck, you can find it here and my demo files here (you'll need to download the SDK and CodePlex toolkit and tool separately).

For those of you who joined me at VSLive! this week in San Francisco, I had fun sharing many worst (or un-preferred) practices I've run into over the years. My talk broke them down into several areas: TFS installation, TFS configuration, team projects, work items, and version control. Hopefully I didn't make anyone feel tool uncomfortable when I highlighted your practice on the big screen!

Actually, it was all in good fun. By highlighting Team System worst practices, we were able to define Team System best practices and preferred practices.

If you'd like to have a look at my slide deck, you can find it here and my demo files here.

Feel free to let me know about any other worst or worster practices you may know of.

Since first seeing the Code Metrics feature in the Development Edition of Visual Studio Team System 2008, I've been on a quest for bad (read: unmanageable) code. Rather than face the tool towards my code, I thought I would pick on Microsoft.

... and it looks like the EntLib has a maintainability index between 77 and 89.

Thanks to Ajoy krishnamoorthy for actually doing the hard work on this.

Back home now, and I have a moment to get the photos downloaded from my camera and uploaded to my blog. Next time I'll take my SD card reader with me.

As you can see, registration was quite busy. I heard that there were 4000 people there, but didn't count them myself. The long lines delayed the keynote by about an hour:

Douglas McDowell and I snuck into the press area. Well, he was officially press (SQL Server Magazine), but I wasn't - still I took more notes than most of the other pressies there.

The main screen was huge, and 3D. We estimated about 80' wide and 20' tall. When no slides were on the screen, there was a spinning 3D Earth enclosed in curley brackets. Hey, what about VB?

After the keynote, there was a short walk to the LA convention center, where the breakout sessions, chalk-talks, exhibitor area, etc. Fortunately, we had these interpretive dancers along the way to keep us from getting lost.

The line to lunch was too long, so we ducked inside to check out the exhibitor area.

I was there (where it says "You Are Here")

Attendees attending one of Doug Seven's chalk talks on Team System.

Doug was all about the writing quality code and the 3 C's in his talk (Code Coverage, Code Analysis, and the new Code Metrics)

After I turned in my evaluation form, I picked up the attendee bag, which had  lots of goodies, including a hard-bound, coffee-table style book called "Heroes Happen Here" which contains IT heroes from all around the world, photographed by Carolyn Jones. And yes, I got my book signed!

In this, my first post of (hopefully) several today, I'm sitting in the keynote session (next to Douglas McDowell), listening to Tom Brokaw warm up the audience. What a nice surprise. It definitely stopped all the geeks in their tracks, to listen to his wise words, gathered from years of experience in all matters mankind.

I loved his opening line "I'm not here to write code, or wire this room". He did, however, wax poetic on the future of technology, the spirit and energy of the types of people who will drive it, and how we must handle it to get their safely."

Some of his quotes during the keynote (some paraphrasing):

• "The test or our place in this world is not yet complete. We don't want to become Easter Island or the Mayan civilization. The use of this technology is not just a virtual experience. If we develop capacity and leave out common sense, what then is the reward to each of us, collectively or individually? If speed overruns reason, what else gets trampled?"
• "We will not solve climate change by hitting backspace. It will do us little good to wire the world if we short circuit our consciousness, our souls and if we don't use this technology to advance mankind."
• "When I left Nightly News I said that I'm not only going to spend my time at suites in the four seasons ... but to spend time in the trenches to meet people who make a difference"
• "One day I woke up in Pakistan in a packing container with Americans who had been there for six months, trying to assess medical and health needs. When they hiked out, they put their hands on the keyboard and distilled what they had learned ... and in so doing, made a big impression ... of those of us in the West who have so much, while they (people in Pakistan) have so little."
• "This technology takes a guiding hand, an imaginative approach, and a hope ..."
• "We have the opportunity to become the next, greatest generation."

Steve Ballmer came on stage next to thank the many platinum sponsors, and discuss how "Dynamic IT" can help manage complexity and achieve agility (especially in the realm software development)

I heard the term "Agile" about 10 times in the span of 3 minutes. More to come ...

10:35 AM (Los Angeles)

A fictitious developer, from the fictitious company "Fourth Coffee" is demonstrating the new, agile development features in Visual Studio 2008. She's showing off how to manage team development projects (a.k.a. team projects and work items), giving her tasks to make some changes to her code. Mostly she is showing off the split-screen editor, synchronization of code and designer, integrated design tools, and the new JavaScript debugger.

Oops, she just called it "Team Services" as she closed out her work item. Well, we get the idea.

I know. I know. This doesn't sound like a very interesting post, but it saved me time, and hopefully it can save you some too.

When you install Visual Studio 2008, Microsoft creates a "Visual Studio 2008 Command Prompt" shortcut, under that program group.

I like to take this shortcut and drop it on my Quick Launch toolbar:

The problem is that when you install the Team Foundation Server Power Tools (or other new command line utilities) you need to put them in the path.

Well, if you look at the file the shortcut calls, it's vcvarsall.bat, but don't bother editing that file because it calls vcvars32.bat, but don't bother editing that file, because it calls vsvars32.bat. If you go ahead and edit that file, you can find where the PATH is getting set, and add the Power Tools path to it:

@set PATH=C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE;C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN;C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools;C:\WINDOWS\Microsoft.NET\Framework\v3.5;C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;C:\Program Files\Microsoft Visual Studio 9.0\VC\VCPackages;C:\Program Files\Microsoft Team Foundation Server 2008 Power Tools;%PATH%

Last week I had a chance to meet some of the brains behind gridGISTICS - a .NET development company in Atlanta that gets it. Not only are they up to speed on the latest .NET 3.x technologies, but they have some killer products as well.

The one that struck me as the coolest was their Aware Server product, which is a grid-computing based deployment and management environment. In other words, the missing pieces to Team Foundation Server's build and (ahem) deploy automation. Packaging up applications by system and version into manifests, these binaries can be automatically deployed, registered, launched, and monitored by various Aware Agents installed around a company's environment. From the development side, they provide many Visual Studio 2008 templates and add-ins to help generate Aware-compatible applications very quickly.

Follow their story here.

Come chat with the Visual Studio Team System group on Wednesday, December 5th.

Join members of the Visual Studio Team System product group to discuss features available in Team Foundation Server, Team Suite, Architecture Edition, Development Edition, Database Edition, and Test Edition. In addition, discuss what's new for these editions for Visual Studio 2008.

There will be two sessions that day:

• 10:00am - 11:00am Pacific Time (Add to Calendar)
• 4:00pm - 5:00pm Pacific Time (Add to Calendar)

Microsoft has released a new version of VSTS Web Access Power tool. This release is a Community Technology Preview (CTP) of what will ultimately be the 2008 version of the VSTS Web Access Power Tool.

• Built against the TFS 2008 object model - In previous versions of Web Access you had to install Team Explorer 2005 on any machine you were installing Web Access on. With this version, you will now be installing Team Explorer 2008 instead. In some future version, Microsoft hopes to remove the requirement to install any version of Team Explorer.
• Custom control support - added support for web based work item custom controls and have included a folder of documentation and samples on how to create them.
• Build queuing - added UI for the new TFS 2008 feature of build queuing. You can start new queued builds and view the build queue (in addition to the preexisting abilities - like viewing build details).
• Localization support - added support for localizing the web interface. Microsoft will also be localizing text for the final 2008 Power Tool release.
• Bug fixes & Performance improvements - Microsoft has received a number of reports and done more testing on the current version of the Power Tool, and has fixed everything thus far.

This release (and the final 2008 release) can be used with either a TFS 2005 or a TFS 2008 server.  In either case, you will need to install a TFS 2008 Team Explorer on the machine you install Web Access on. Since TFS 2005 did not support build queuing, that functionality will not be available when this and future versions of Web Access are used with a 2005 server.

You can download it here and read more about it at Brian Harry's blog posting.

The great news just keeps on coming from Microsoft. After a flurry of Team System announcements and downloads recently, we have yet another set of Power Tools to play with.

These tools are designed specifically for the Visual Studio Team Edition for Software Architects and provide the following capabilities:

• View class library projects on the Application Diagram (AD)
• View references to class library projects as connections on the Application Diagram
• Create class library projects from the Application Diagram
• Create references to class library projects from the Application Diagram
• Synchronize properties between class library projects and their representative applications on the Application Diagram
• Create and use class library applications and references on the System Designer (SD)

Fantastic. We haven't seen much out of the Architect tools, except for the SDM SDK in quite some time. I'm looking forward to it.

Download the CTP here. Note: you will also need to download Visual Studio 2008 Beta 2.

If you have any feedback on these tools, please visit the Architecture & Design forum.