Why does the Web Client Software Factory MSI install a second MSI?
The installer (MSI) for the Web Client Software Factory does quite a lot. It will install the Help into the Visual Studio help system, It includes an CHM help file as well. The installer also registers the Web Client Software Factory with Visual Studio, and places signed, re-usable DLLs in a folder. This is all pretty basic stuff for an installer to do. The thing that is apparently surprising a few folks is the last thing the installer does is place another installer in the destiantion folder. And, of course, there are shortcuts on the Start menu for all of these things.
This second MSI is all the source code and unit tests for the factory, a number of QuickStarts (as source), and the code for a simple reference implementation. Why did we use a second MSI for all of this? The idea, which came about after a lot of discussion amongst the folks here at patterns & practices, was mostly thanks to Chris Tavares (if I recall correctly), and is also used in the Web Services Software Factory. Basically, you can look at running the source code MSI as getting a clean, labeled copy of the source code from the p&p source control system. It is a snapshot in time. Why? If you are like me, you have grabbed a p&p deliverable (like Enterprise Library), installed it, and started poking around. After a few changes, you have screwed things up, and nothing works anymore, and you are not quite sure why (not that I ever get to this point, of course... ;-) ). This approach gives you the option to have N copies of the code on your box. If I were a user of this, I would do what I ended up doing the first time I used EntLib (after screwing things up) and other p&p deliverables before I joined the team: Create a pristine copy of the code base that I used as reference, and have a working copy that I could play around with without worrying about it.
I hope that helps explain why there is a two step process to get the source code.