Microsoft.WebApplication.targets not found

While setting up a non-Microsoft CI environment for an ASP.NET MVC project, I came across an interesting problem.  My build agent was unable to compile my project because it could not find the Microsoft.WebApplication.targets file, which, on the development computer is located under the C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0\WebApplications directory.

I wanted a quick solution, so I Googled it.  The top two sites resolved the issue by creating the path on the build server and copying the file over.  That is A solution to the problem.  I suppose another solution would be to install Visual Studio on the build agent.  But, that (borderline) defeats the purpose.

I decided to make a copy of the Microsoft.WebApplication.targets file in the folder of the solution.  Then, I opened the web project file and edited the line that points to the file.  I changed:

<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" />

to

<Import Project="$(SolutionDir)\Microsoft.WebApplication.targets" />

The project builds successfully in both environments now!

Advertisement

What I learned about Kanban from Linda Cook

Last night, Jan. 13, 2009, Linda Cook visited the Agile RTP user group and did a presentation on Kanban. I was an attendee.

Linda Cook’s presentation was my formal introduction to Kanban, as well as one of the few presentations that featured Lean principles.  So, here is what I learned:

Kanban is a Japanese word meaning sign board or billboard.  It describes a signaling system to trigger action.  And, it describes a “pull” system where workers/employees pull work from the system, as opposed to work being assigned to a worker.

Work in managed in queues.  Once queue management is optimized, a Kanban team will improve incrementally.

Kanban does not require:

• big upfront planning
• estimates
• fixed cycles (iterations)
• a dedicated team (team members can use part of their time for Kanban projects)

Linda mentioned the “Train Station Model” that one of her teams employed.  It is the idea that code is waiting at the station to be deployed.

Challenges & Criticism

• Kanban is sort of like Waterfall
• It is difficult to determine when to do a retrospective in an iteration-less workflow
• How do you focus on small changes when the team wants a whole new system
• There are limited tools available to support Kanban

Flow rate = the average time it takes for a task to go from creation to completion.  Flow rate can help determine estimates of future work.  *I wonder if this can lead to dynamic estimates?  As flow rate changes, projections on future work should change also.

Tools and supplies

For one of Linda’s teams, she used the following tools to manage the Kanban process:

• A Whiteboard
• Stickies, three colors (Yellow to record tasks, Pink to record problems, and Green to record acceptance criteria)
• Marker pens
• A rubber date stamp (to stamp the “born-on-date” on the stickies)

In practice, she suggests the following:

• Measure flow rate constantly
• Graph your flow rate
• Planning is ad hoc and should not require a meeting
• Plan constantly
• Allow stories to be added when they are discovered
• Don’t allow changes to anything that is in the Work-In-Progress queue
• Per task, only use the necessary people for the task to plan

General Kanban process

• All tasks are stored in a “pool”
• The Business moves items from the pool into the Backlog queue
• Workers/Employees move items from the Backlog queue to the Work-In-Progress queue (someone suggested using a Specify queue between the Backlog and WIP queue for task-specific requirements gathering)
• After WIP, the tasks are moved to a Testing queue
• From Testing, the tasks move to Done