19 October 2006

Document: From VSS to TFS - An Introduction to Team Foundation Server Version Control from a Visual SourceSafe User's Perspective

Over the course of the last few months, I have been part of a team working to bring TFS Version Control and MSBuild into my organization. My duties have included everything from process definition to hands-on migration of code from VSS into our TFS repository. An additional (and unwritten) role that I have assumed is to help our developers, QA, and Infrastructure people make the mental transition from the way VSS did things to the way TFS does them. This document was born out of those discussions. I decided to write this up with screenshots from the Version Control Tree Browser project on CodePlex so that it would not have any proprietary corporate information within it. That will allow me to post this for general public consumption without losing my job.

Please feel free to download and use it within your own organizations if you think it is worthwhile. I would appreciate a comment to this posting if you like it, but more importantly, if you don't. If there's anything I've missed or misrepresented, please let me know and I'll do my best to fix it. This document will grow with your feedback, so please give all you can.

Thanks,

- Steve

Download: From VSS to TFS

Update: Well it looks like I've had to make my first update. Buck Hodges dropped me an email calling me out on the statement that Microsoft will ship an option to allow automatic Get Latest during Check-out. I don't remember exactly where I picked that tidbit up, but I guess it wasn't as reliable as I thought. I've updated the doc to reflect that this feature has been asked for and will be in a future release of Visual Studio. Buck actually said that he couldn't specify if or when a feature would be added to VS ( probably to cover his butt :) ), but I believe that this is important enough to the VSS-transition crowd that it will eventually get into the product.

Updated Update: It looks like the updated PDF didn't get onto my hosting space correctly. I've had a couple of comments regarding the file being corrupt. I've uploaded the file again and checked it from my home connection and it seems to be Ok. Blogger was also down intermittently between 19-Oct and 22-Oct which didn't help. Everything should be fine now. Please let me know if you come across any further issues. - Steve

Another Update: The PDF file linked on ManicProgrammer.com was lost in a violent database crash. I have uploaded a new version and modified the link above to point to it. Sorry for the inconvenience. - Steve [26-Mar-2009]

12 October 2006

TFS Resource List from the CodePlex Team

I was fortunate to have had a conversation with George Bullock, Program Manager of CodePlex while standing in line waiting for a latte (that's Seattle-an for coffee).  We got to discussing my use of the CodePlex site while working on the Vertigo project and TFS in general.  He was kind enough to send over a list of resources compiled by Pete Coupland, Test Lead for CodePlex.  I'd like to thank both George and Pete for this information.  Here a bit of clipboard-inheritance (aka copy-paste) of George's email back to me:

"Steve, here's an incredible list put together by Pete Coupland, test lead for CodePlex; thanks Pete!

http://msdn.microsoft.com/vstudio/teamsystem/products/tfs/default.aspx
http://msdn.microsoft.com/vstudio/teamsystem/support/faqs/foundation_techfaq/default.aspx

Team System Educational Videos (Walkthroughs): http://msdn2.microsoft.com/en-us/library/ms181244.aspx

Team Foundation Server Help Documentation on MSDN: http://msdn2.microsoft.com/en-us/library/ms181232.aspx

Team System Learning site: http://msdn.microsoft.com/vstudio/teamsystem/learning/

Team System Forums: http://forums.microsoft.com/msdn/default.aspx?forumgroupid=5&siteid=1

Visual Studio Team System Webcasts: http://www.microsoft.com/events/series/msdnvsts2005.mspx

Team System Featured Group on GotDotNet's CodeGallery: http://www.gotdotnet.com/codegallery/directory.aspx?GID=33927aa0-7052-42d3-9fab-d03136b4b666*

Visual Studio 2005 Team Foundation Server MSSCCI Provider: http://www.microsoft.com/downloads/details.aspx?FamilyID=87e1ffbd-a484-4c3a-8776-d560ab1e6198&DisplayLang=en

Blogs

List of all Team System Bloggers: http://msdn.microsoft.com/vstudio/teamsystem/community/blogs/default.aspx

Star Bloggers

Rob Caron's Blog - "A Team System Nexus": http://blogs.msdn.com/robcaron/

Buck Hodges: http://blogs.msdn.com/buckh/

Visual Studio Team System User Education Blog: http://blogs.msdn.com/vstsue/"

Patterns & Practices Summit - Day 4: Software Factories

Steve got burned today by "the day job."  I was really "jazzed" about today's topic, but (there's always a but) unfortunately, I had to work through some issues in our build and deployment process and was unable to listen and take notes on most of the morning sessions and Chris Kinsman's Services Factory presentation.  I am not happy about this, but that's life.  I apologize to both of my subscribers. David was able to get more notes than I was, so pop over to his blog and read all about it.

- Steve

 

Keynote: Architectural Guidance with Software Factories - Jack Greenfield
Working on and off during the discussion, so the notes are sparse.  Jack gave an overview of the the PnP ideas around Factories.  This set the foundation for the rest of the presentations today.  His presentation went long (there's just way too much info on this for a single hour) so there was not time for Q&A, that was generally considered to be a bummer.

Session 1: SI & Designing for Operations - David Aiken
Work got in the way

Session 2: Smart Client Software Factory - Wojtek Kozaczynski
Work got in the way again

Session 3: Services Software Factory - Chris Kinsman
Yup, still working...

Session 4: Web Client Software Factory - Michael Puleio
Hoping to be finished soon...
Luckily, I'm sitting 3 time zones west of my office and they have all gone home.  More notes to follow...

Session 5: TDD and Guidance Automation - Chris Tavares
Chris gave us a review of how testing of Guidance Automation Packages is done.  If you are building any packages, you will want to review his talk.  It seems that trying to do TDD in this aren is really really hard.  Because you are working against the Visual Studio IDE, you can find that you are easily becoming bogged down in testing Visual Studio. To get around this, Chris recommends creating an interface and mocking Visual Studio.  Here are some notes fromthe session:

Guidance Automation Toolkit

  • Authoring environment (sort of)
  • VSIP Package
    • Does the painful stuff so you don't have to
  • Hook up UI to gestures in VS
    • Context menus
  • User Interface
    • Wizard framework (hook to existing framework)
  • Reusable actions

Guidance Automation Extensions

  • Runtime
  • Sits inside VS and runs VSIP package

Guidance Package

  • A combination of
    • Recipes
    • Project and Item templates
    • Snippets
    • Written Guidance
    • Example code

Recipes

  • Reference
    • Answers the question, "Can this recipe be run now?"
    • Needs to query on the current state of the project
      • What is currently selected
      • What does that thing contain
      • The rest of the project
  • Arguments
    • Dictionary of name/value pairs
    • Argument types are typed
    • ValueProvider
    • TypeConverter
  • Wizard
    • "Standard" pages
      • XML configuration driven
      • Map directly to argument fields
    • Custom pages
      • User controls
    • Standard wizard frame
  • Actions
    • Object that actually does the work
      • Codegen
      • Project configuration changes
    • Configuration hooks them to arguments
      • Potentially reusable across recipes

T4 Template Engine

  • Looks like Classic ASP and CodeSmith templates
  • Uses inconsistent syntax from above

Building Testable Guidance Packages

  • "If you can't test it, make it so stupid it can't break."

Presenter First Pattern

Closing Keynote: Architecture Evaluation in Practice - Dragos Manolescu
Dragos ran through the difference between the "State of the Art" of Architecture Evaluation and the "Reality" of Architecture Evaluation.  He didn't give a training session on what Architecture Evaluation actually is, but rather how to go about doing it in an "opportunistic manner".  He recommends adapting the theory to your specific project needs.  The discussion was a bit esoteric with regard to my needs. 

That's it from Redmond!  Time to get ready to fly back to the right-coast.

11 October 2006

Patterns & Practices Summit - Day 3: Development

The overarching theme today was how to use Agile methodologies to build better software.  Keith Pleas posted my and David's blog URLs on screen with the request that anyone else blogging here this week let him know.  If you are here in Redmond and have been blogging about the conference, please leave me a comment with your blog address, I'd love to read your thoughts.

Keynote: The Future of Patterns & Practices - Rick Maguire
Rick discussed where the PnP team is going over FY '07. 

  FY 07 - H1   FY 07 - H2
User Experience Mobile Client Software Factory   Client Architecture Guide
  Web Client Software Factory v1   SC Software Factory v2 (fy08)
      Web Client Software Factory v2
       
Web Services & integration Services Software Factory v1 (asmx)   Services Software Factory for Orcas - FIAT (FY08)
  Services Software Factory v2 (WCF)   .NET 3.0 Architecture Guide
       
Engineering Practices Design for Operations   Enterprise Library TNG
      Guidance Explorer
       
MSF MSF Updates   MSF Updates
  MSF Orcas (FY08 Deliverable)    

 

 Session 1: The Agile Talk on Agility - Peter Provost & Michael Puleio
All I can say is "BRILLIANT!"  Peter and Michael broke the session out into 10 minute iterations in which they first asked the audience for a list of topics to discuss.  We dealt with scope creep in the backlog, when an Agile process will and will not work, managing distributed teams, and architecture.  This discussion validated our internal processes and was entertaining and informative to boot.  Here's my notes on each interation:

Iteration 1

  • Estimation
    • Yesterday's Weather
    • Estimation rules:
      • Collaborative approach
      • Teams talk it through to gain consensus
      • "Poker cards" method
      • Collaborative estimating model
      • Person doing estimating is person doing the work.
  • When will agile not work
    • When you have a very well know problem space with well defined limits
    • When the team hasn't bought into the process (working together, deliver small chunks of functionality)
    • Philosophy - "The best time to make a decision is not always way in advance, nor is it very late" The right time is the last responsible moment, not before, not later.

 

Iteration 2

  • How do you design and Architecture in an Agile Project?
    • Do it a little bit at a time
      • TDD, Refactoring
      • Clean up design as you go
      • Skeleton architectures
      • "Metaphor"
        • create a high-level architecture before any code is written
        • Shadow Architecture, Skeleton Architecture
        • but know how deep to go
          • use simple flow charts and package diagrams
          • do not use activity diagrams
  • Managing Distributed teams
    • Bring the entire team together as frequently as possible
      • Does not mean constantly
      • Remote sharing
      • IM
    • Do more upfront design
    • Last responsible moment for a distributed team is just before they start coding.
    • Make separate, complete, small teams (dev, test, coordination) at each location.

 

Iteration 3

  • Scope creep that causes a problem with existing architecture
    • Management
      • Lots of unit test
      • Lost of acceptance tests
      • Heavy QA presence (2 QA to 1 Dev)
    • Make sure backlog is stack-ranked by the customer so you are always building the feature that is most-important to the customer right-now.
  • Risk Mitigation and Design
    • "Last Responsible Moment to Decide"
    • Risk determines stack rank

 

Session 2: Continuous Integration - Wayne Allen
Wayne gave an overview of CI processes from Stage 0 (no CI process), through Stage 1 (daily build and smoketest), to Stage 2 (standard CI process).  We have a mature Stage 2 CI process in-house and this presentation seemed to be a validation of our internal processes.  Because my organization is ahead of the CI curve as compared to many of the other organizations represented in the room, I would have like to see more detail in areas like Dealing with Internal Project Dependencies.  I did like that he brought up automated testing of installers.  I'm going to have to add that to my team's backlog.

 

Session 3: Presenting the Model - Brad Wilson
Brad presented a discussion of the Model-View-Presenter pattern and it's applicability to testing UIs.  While you can't specifically test the UI elements, such as buttons or text boxes with this pattern, you can get just "under the glass" to test all of the non-visible aspects of the UI.  The big benefit of MVP is that you can test heretofore "untestable" code if it was tightly coupled to the presentation (controls) code.  This is a very powerful pattern when coupled with a "test-based" (not strictly TDD) development methodology.

 

Session 4: Agile Testing Guidance - Alan Ridlehoover
Another great session.  Alan discussed ways to increase the quality of the software you ship using agile methods, such as TDD and Continuous Integration.  The main gist of the discussion is that agility is not simple, but the benefits are significant.  Here's some notes:

Writing tests during development gives you regression tests for free

  • Disciplined about writing tests
  • Never add or modify functionality without a failing test
  • Without a failing test, there is no requirement for new code.
  • Without test, specification falls out of sync with the code.

Incremental design and refactoring

  • Prunes out old dead code
  • Start with a simple solution one requirement at a time
    • They reduce maintenance costs
    • Incremental design produces values with minimum investment

Never redesign while a test is failing

  • Tests offer you a safety net for your modifications
  • Design changes should not be externally visible
  • Failing tests may mask design problems

Integrate frequently

  • Small changes integrate more easily than large ones
  • Forces developers to run tests frequently
  • Integrated code is more valuable to the organization

Integrate locally before check-in

  • Code in the repository must always be deployable
  • Insures that code runs on multiple workstations
  • Build server is community property
  • The build server is not your personal test rig
  • Someone else may have just broken the build

Failing build freezes all development until fixed

  • If the CI build is broken then you are adding code to an foundation that is not solid.

 

Session 5: Patterns for Distributed Systems: Core WCF Patterns - Ted Neward
Ted gave a rousing discussion.  He started with calisthenics for audience, some shoulder rolls and a threat of jumping-jacks create a sense of attentiveness within the audience.  After he finished off with us, he got down to discussing the how we can find "Best Practices" for a product that is so new.  His response was to look at other development arenas that have similar tools, but have had more time to mature, like J2EE.  One of the reference books Ted used in his talk was Core J2EE Patterns.

 

Session 6: Micro-Pairing - Peter Provost & Brad Wilson
Peter and Brad started off with a small slide deck that described their version of pair-programming.  They moved into a demonstration of the process for the next 30 minutes.  As one was writing a test or making it pass, the other was having a discussion with the audience.  This was a very informative and amusing session.  The basis of their pairing process is to "Pass the keyboard at every TDD Step".   Here's the notes:

What is it?

  • 2 developers at 1 computer
  • Driver
  • Observer
  • Test Driven Design

Do it together

  • Pass the keyboard at every TDD step

Successful pair development produces better design

  • real-time code review

The least knowledgeable person is responsible for implementing the feature

  • Knowledge transfer
  • Problem domain learning
  • Levels team knowledge
  • Probably has lower velocity
  • Grows junior people

Grow junior people, fire problem children

Negotiate over your disagreements

  • Design is steered by decisions made in the test

Writing a test that immediately passes is called "documenting existing behavior"

Good Reference

So as you can see, another great day of content here in Redmond.  My tour of the Patterns & Practices workspace has been postponed until tomorrow, so I'll have those pics for you then.

Patterns and Practices Summit - Day 2: Patterns

This is the Day 2 notes.  My co-worker David Boss is also blogging about the conference, but his updates are happening in real-time with posts after each session. 

Keynote: Architecture for Next Generation Web Applications - Scott Isaacs
Discussion of Web 2.0 and Mash-ups in the context of the architecture of Windows Live properties.  This is one of the first times I've come across the term "mash-up", so here's the definition given by Scott:

"Web Applications that consume (remixes) content and experience from different sources and aggregates them to create a new experience."

Scott also discussed enabling technologies, such as RSS, SSE and Microformats.  A quick demo of Live Clipboard was given.

Here are some of the links given:

Microformats: http://www.microformats.org
Microsoft Gadgets: http://www.microsoftgadgets.com
ASP.Net AJAX (Atlas): http://atlas.asp.net
Live Clipboard: http://spaces.live.com/editorial/rayozzie/demo/liv...

 

Session 1: Evolving to Patterns -  Jim Newkirk
Jim gave an excellent discussion on Evolutionary Design and evolving your code to patterns.  I'm lucky enough to work in a company that has a commitment to pattern-based development, so there was nothing new to me in this discussion.  With that said, it is important to realize the by definition, Patterns are not new, but rather solutions to commonly encountered problems that can now be discussed and described by a common vocabulary.

Here are some of the points that Jim made that resonated with me:

A New Metaphor

Let's forget the building architecture metaphor

Code is more malleable

Much more akin to Landscape Architecture

 

Patterns

When to apply

  • Apply during design
  • Apply when you see bad code

Simple rule of thumb

  • Second person pays
  • Introduce the pattern the second time you need the functionality.

 

Technical Debt

Occurs

  • Whenever you do something to reduce flexibility, you incur technical debt. (Hacks, compromises)
  • When debt is too high you rewrite (bankruptcy)

To fix

  • Remove duplication
  • Simplify code
  • Clarify your code's content

It is your responsibility to "clean as you go." You should always be cleaning the code.

 

Test Isolation

  • Make one change to cause a single test failure and see which other tests fail.
  • Shows good/bad test isolation
  • Shows objects that have dependencies that may need refactoring
  • Solve by using Stubs / Mocks

 

Session 2: Agile Presentation Layer Design - Andrew Flick (Product Manager, Infragistics) 
I haven't been involved in UI design and development for many years now, so it was nice to hear more about this topic.  With that said, I don't think an audience of developers and architects is necessarily the correect one for this talk.  He threw out a quote that I think backs up my assertion:

"Do engineers build bridges?  No, steelworkers build bridges."

Another good quote is:

"The design isn't complete when everything that is needed is in, but rather when everything that is not needed is removed."

 

Session 3: Contractual Zen - Scott Hanselman, Patrick Cauldwell
Scott and Patrick tag-teamed through this presentation, handing off easily from one to the other, sometimes in mid-sentence.  It was a lot of information, so some of the items passed by me pretty quiclky, but luckily, my company is doing similar things. 

The gist of the discussion was that you can make your life easier and make your customers happier byt providing them with a contract-based API that they can program against while offering you the ability to make refactorings against the underlying legacy code.

Here is the synopsis:

Contraxploitation

Think:

  • About your service description
  • About multiple transports

Do:

  • Exploit your Contracts
  • Extend your reach to other systems
  • Put a stake in the ground

Feel:

  • Enabled to generate more code
  • Comforted by your layers of abstraction

 

Session 4: Security Patterns for Services -  Jason Hogg
A very smart guy talking about security stuff.  Here's my notes: "Blah blah blah web service blah blah blah WCF blah blah blah blah security blah blah encryption blah blah blah patterns."  Sorry if you aren't getting anything out of this one, but that's all I got out of it.  Looks like I might have to brush up on my WS security and encryption.  There was a bit about the Web Service Factory, but I was working on office stuff during that part.  I can't multitask, period.  I've been told that it was very interesting. 

 

Session 5: Versioning Web Services 2.0 - Don Smith
Don was more putting forth ideas around some versioning guidance possibly due out in December.  His contention on versioning is that your contract's members should all be optional and the validation of the data in the request message should occur on the receiving end.  I worked on an integration project last year that used this pattern to allow for integration between two disparate systems in my organization while leaving the two component systems decoupled from each other.  It worked very well.

 

Session 6: Reengineering to support workflow - Billy Hollis
Billy gave a great talk on workflow and workflow foundation.  Workflow foundation is going to be very helpful to any enterprise that needs to model and implement their business processes, like mine.  Here are some notes I took:

Types of workflow

Sequential workflow

  • flowchart-like workflow
  • Prescriptive, static

State machine workflow

  • Graph metaphor
  • Reactive, event-driven
  • Skip steps, go back, rework, handle exceptional cases

Elements of workflow

  • Work items - items to be worked on, documents, orders, prescriptions, etc
  • Rules/process (flow) - rules and logic that tell how items are to be worked upon

WF Tech Basics

  • Workflow is all composed of "activities"
    • Basic activity - individual step
    • Composite activity - contains other activities
    • Base activity library - OOB activity set
    • Expected third -party ecosystem
  • Workflow engine manages the activities and manages communications to outside processes
  • Workflow is hosted in some external host process (Windows Service, Windows Forms exe, console app, etc.)

WF Limitations

  • Does not address distributed workflows
    • You need your own architecture /design
  • Rules engine has no front-end
  • Limited connectors at first

Just like yesterday, itlate and time for bed.  Tomorrow is devoted to Development.  Should be a lot of great stuff.  If you haven't already guessed, I highly recommend attending this conference if you can.

Just as an FYI, Don Smith offered a tour of the new PnP workspace on campus.  I'll be going tomorrow with a small group of attendees.  I'll bring my camera and post some pics tomorrow.

- Steve

10 October 2006

Patterns & Practices Summit - Day 1 - Frameworks

I'm not sure how I want to write about the conference. I was thinking that I could post notes that I have written about it or my thoughts on the content presented. I think that in the final equation, I really want to be able to do both. You can also read the thoughts of my co-worker, David Boss, who is also blogging about the conference.

I started using OneNote 2003 today to take notes during the Summit. I had heard great things about this app from co-workers that use it regularly. This seemed to be a perfect occasion to give it a test drive. My thoughtsSFD - Chief Seattle: FANTASTIC! I was able to keep notes where I needed to augment the slides the presenters showed in a "free-form" way.

I'm also going to drop in a few pictures that I took of Seattle over the past weekend to add a little "flavor" to the week's posts.

With that said, here goes...

Day 1 of the Patterns & Practices Summit was focused on Framework development. I was very impressed with the content present from all of today's speakers. This conference had the smallest attendance of any that I have been to (around 250 or so), but I think that it was a benefit. We were all able to ask our questions and get meaningful answers with plenty of time to spare.

Presentations:

Keynote: Framework Design Principles - Brad Abrams - Blog & Slide Deck This was an excellent session on the essentials of framework design. Brad brought out 5 major points:

  1. Treat Simplicity as a Feature
  2. Know your User
  3. Think of the Development Ecosystem
  4. Use the Power of Consistency
  5. Design to Last

Some of the more salient points include:

  • "We're not just shipping just your feature!" (Craig Symonds, General Manager Visual Studio) - You may have to make your piece sub-optimal to keep consistent with the overall framework.
  • "Limit the amount of New()" - From a discoverability standpoint, it is better for the user to create a single top-level object that exposes a set of sub-objects than to have to try to figure out which object to instantiate next. This allows Intellisense to be your friend.
  • "Make the Simple Things Simple and the Hard Things Possible" - 'nuff said!
  • Keep Naming Consistent - Save the best names for the most commonly used objects. Be consistent across the entire framework.
  • Addition by Subtraction - You can create a better product by not adding more features. Keep complexity low.
  • "The Pit of Success: in stark contrast to a summit, a peak, or a journey across a desert to find victory through many trials and surprises, we want our customers to simply fall into winning practices by using our platform and frameworks. To the extent that we make it easy to get into trouble we fail." - Rico Mariani

Session 1: Dependency Injection - Brad Wilson Another good session. Talks about ObjectBuilder and how it can help when assembling a system from disparate parts using lightweight containers that serve up those objects to consumers. Here is an article on the subject of Dependency injection from Martin Fowler if you'd like to read more. After the conference is over, I'll try to post a link to any information Brad puts up. Here is the link to ObjectBuilder on CodePlex.

Session 2: Enterprise Library 3.0 - Tom Hollander This was an interesting session, but since we don't use the Enterprise Library, it was a bit off target for me. Now with that said, I did get one thing out of it that was well worth the time spent. Tom discussed how your can allow your test classes to see the non-public members of the class that they are testing. You apply the <InternalsVisibleTo> attribute to your class and you point it at the test class...voila! you can now test your private and protected members and methods. Here is the link to the attribute on MSDN. I also did a quick search and found 2 (Post 1 / Post 2) more blog posts that discuss this wonderful, but little know sanity-saver.

Session 3: Spec Explorer - Microsoft Research This was a brown-bag session during lunch where the Research folks showed us a tool that they are building that allows you to created activity diagrams and it will generate tests based on those diagrams. I can't do justice to the tool, so here's the link to Spec Explorer's page on Microsoft Research's site.

Session 4: CSLA.NET: Lessons Learned - Rocky Lhotka Now I have to admit that I like Rocky's work and his down-to-earth style. He went through some of the trade-offs and decision points that he had to make during the update of the CSLA framework from v1.x to v2 and beyond. A few quotes (some not exactly quote, but close enough) that I thought were important:

"In an Enterprise, frameworks are a key to success."

"For a successful framework, you have to be willing to restrict choices"

"For any framework, non-goals are as important as goals."

"Formalize, abstract and simplify the lives of developers by codifying best practices and standards into a framework."

Session 5: Application Framework Projects in IT - Jonathan Wanagel This session was the hilight of the day. I rated it a 6 out of 5. Jonathan hit on a topic that the folks at my company have been struggling with for years now. We have a number of frameworks in place and keep creating new ones. Here are some of his points on framework creation and design:

"What are the value-add opportunities that a framework will provide to my company?"

"The customers (end users) are the developers. Rejection by the developers will kill the framework."

"Frameworks that go wrong are expensive intellectual playgrounds"

"You must be pragmatic in your approach."

"Indulgence is the enemy of framework design"

"Frameworks are pragmatic, not holistic"

Discovering Value-Add Opportunities

  • Mine the existing frameworks in the organization.
    • Easy to find, hard to determine the value-add of the feature
  • Analyze the design and code of existing code
    • Look fore repetition
    • Look for design mistakes

Jonathan also gave a number of Patterns and Anti-Patterns for framework design. As I said, an excellent session overall.

Session 6: Architecting for Security - Shawn Veney While humorous and entertaining, this session was not as applicable to my job as some of the prior ones. His discussion was aimed at Architects that have responsibility for doing threat assessment and mitigation. We have a separate group that is responsible for that, so I basically sat around eating Hershey's Dark Chocolate miniatures for an hour. Mmmmmm!!

Session 7: Generating Skeletal Baseline Applications - David Trowbridge - Marc Groves This session discussed using the DSL tools in VS 2005 and Orcas to generate skeletal apps for your devs to flesh out. While the tool is neat to look at, it's benefits are minimal. It will probably save a few hours by not having to hand code a few stub classes and methods at the beginning of a project. The longer the project runs, the lower the benefit realized. Seems like they could better use the time to make other parts of the system better. It's the old 80/20 rule being ignored again.

Man! This writing stuff is hard! I'm going to bed. If you are all nice to me, tomorrow I'll tell you a story about "Patterns & Practices Summit - Day 2: Patterns"

- Steve

08 October 2006

He's not my Boss anymore!

It's time again for a hearty blogospheric (is that a word?) welcome to a man that is not only a good friend, but also no longer my dev lead.   I'd like to introduce David Boss (yes, that's his real name) to you all.  He's a very bright man that I have the utmost professional respect for (notice I didn't mention personal...sorry David).

Anywho...David has a background in the theater as well as software development, so I'm sure you all will be seeing that side of him in his postings.

Welcome David!

- Steve

06 October 2006

TFS - Team Build - On failed build assign workitem to a specific user

Problem:

I just came across a post on the MSDN TFS forums that was asking how you go about assigning the workitem created on a failed build to a specific user.  I have also been asked to do this in my organization. 

Background:

Team Build will create a new workitem in your Team Project when a build fails.  The "task" is assigned to the account that ran the build.  In my case, that account is a build service account.  One of my Dev Leads asked how we could modify the build process to make the assignment to him whenever one of his builds failed.  I didn't have time to look into it, so I pretty much blew him off.  I recently had some time to look back into this subject.

Solution:

I figured that I'd probably have to override the CreateWorkItem target to add an additional "AssignedTo" parameter to the call, but after looking through the interface for that task (using the wonderful Reflector program by Lutz Roeder) I came to the realization that the CreateWorkItem task doesn't expose an AssignTo property.  After a little experimentation and research I came to realize that the TFSBuild.proj file has a property called WorkItemFieldValues which is a semi-colon delimited list of work item object property names and values of properties that are not exposed directly by the CreateWorkItem task.  So all you have to do is add an additional name-value pair called "Assigned To" to the property, like so:

 

   1:      <!--  WorkItemFieldValues
2: Add/edit key value pairs to set
3: values for fields in the work item
4: created
during the build process.
5: Please make sure the field names are
6: valid
for the work item type being
7: used.
8: -->
9: <WorkItemFieldValues>
10:
Assigned To=St. Jean, Steven;
11: Symptom=build break;
12: Steps To Reproduce=Start the build
13: using Team Build
14: </WorkItemFieldValues>

One thing to notice, the "Assigned To" property has a space in the name, "AssignedTo" doesn't work.  Upon first glance, you would think that the Value for the Assigned To property would be the user's credentials in the for DOMAIN\Username but that isn't so.  If you do use the DOMAIN\Username for the Value, a workitem will not be created for the build failure and you will receive the following message in your build log:


MSBUILD : warning : TF42095: A work item could not be created for build failure. An invalid value was passed for field Assigned To.


To get the work item to be assigned correctly you have to use the person's name as it appears in other TFS workitems with the format LastName, FirstName.  So as you can see above, the failed build workitem will be assigned to me using the key-value pair of Assigned To=St. Jean, Steven;.


A complete list of the keys that you can use in this property can be found in the MSDN documentation on the CoreField enumeration.


I hope this saves someone else a bit of time and frustration.


- Steve

05 October 2006

Off to the Patterns & Practices Summit in Redmond

I'm heading out this weekend to the Seattle area to attend the Patterns & Practices Summit at the Microsoft Conference Center.  The Patterns & Practices Summit site describes it like so:

"The international patterns & practices Summit showcases the official Microsoft "patterns and practices" for developers, designers, and solutions architects who need to learn how to integrate architectural design patterns and procedures with the technology provided by Microsoft's .NET platform.

The patterns & practices Summit packs into four full days unique presentations offered by many of the industry's best speakers. An evening reception sponsored by Infragistics will give attendees an opportunity to meet with Microsoft personnel. Attendees will come away with a strong foundation in the architectural principles underlying Microsoft's .NET technology, which will prepare them to construct the next generation of enterprise-scale applications."

This is my first time attending this conference and I'm extremely excited.  I've spoken with prior attendees that have raved about the depth and breadth of the content.  If you are an architect or are working to become one, you should be attending.  If you are attending, hunt me down.  If I have told you in the past that I owe you a beer, this is the perfect time to collect the debt.

- Steve