One of the easiest decisions to make when embarking on a Silverlight development adventure, is to decide to use a Source Code Manager (SCM) to keep the myriad projects and files organized.

I shall leave it up to you to decide which SCM to use.

As far as setting up the SCM environment, there are treatises elsewhere (I hope) on the philosophical disagreement on setting up releases, branches and code progression paths in SCM.

As for me and my house, we have standardized on a very small implementation of SCM philosophy.

First, with regard to promotion and versions:

1. The Production code is the Top level Branch.
2. Below that is the Staging code (for us, Staging is where real users do testing).
3. Below Staging is the QA code (QA is where certain  designated project testers do testing).
4. Below QA is the Dev code (Dev represents the latest version of the code that has been promoted from each of the developers.  This is used for integration and unit testing, and is the place where developers test their contributions after they have finished their local coding/testing effort.  There is an automated build process that builds, tests and deploys (if build is successful) the compiled project to the Dev server for integration testing.
5. Below the Dev code are the individual workspaces for each developer.  Each developer can create workspaces off the Dev branch.  They are free to make their changes in their workspaces, and their changes are isolated from:
   a) the integration build on the Dev server;
   b) other developer’s “work in process”; and
   c) their own experiments and “not for this release” changes.
6. Code is promoted from each developer’s workspace to the main Dev branch.  It is then occasionally promoted from the Dev branch to QA for testing.  When it passes it is promoted to Staging for testing.  When that passes the code is promoted to Production on the release schedule.For example:
   

Second, with regard to tools and dependencies:

1. In the DV branch, there is a folder called Installations, where we keep the installers for all of the tools we use.  This serves two purposes: a) it centralizes the installs so rebuilding a dev environment is not such a chore; b) it makes sure that all the dev environments are using the same versions of the same tools.  We have also checked in a readme.txt for each tool documenting our licenses, download locations, vendor logins, etc., needed to obtain the file from its source or to get updates.  This folder is then “cloaked” in our SCM to ensure that it is not promoted up to the QA branch.  Developers can cloak it in their branch once they have installed everything and configured their environment so that they can delete the install files and reclaim that space.

   

2. In the DV branch there is a folder called Dependencies, where we keep all the DLL’s and third party references.  All projects in the solution(s) then reference the DLL’s from the Dependencies folder, and NOT from their local Program Files installation of the tool in question.  This serves two purposes:  a) it ensures that, regardless of which version of which tool is installed locally, that all of the DLL’s required to compile the app are in SCM and are in a folder that has the same relative path (i.e. ..\dependencies) on every developer’s hard drive.   This avoids so many seemingly random errors that crop up when a developer links a project to their own Program Files menu.  NOTE:  This pretty much invalidates the use of “Add Reference, Select from List” for all but the core MS DLL’s, as you will almost always have to pick “Add Reference, Browse” to get the reference to point to the Dependencies folder.  It also means that most project creation wizards will produce a project that you then have to remove and recreate the references in so that they point to the Dependencies folder that the wizard knew nothing about.In our projects, DLL’s from: C:\Program Files\Reference Assemblies and C:\WINDOWS\Microsoft.NET, are referenced from those locations, all other DLL’s are referenced from the copies stored in the Dependencies folder.  For example, the C:\Program Files\Microsoft SDKs\Silverlight\v3.0\Libraries folders are copied over to the Dependencies\Silverlight\Libraries folder.