How would I split a single-solution website into multiple solutions (NOT multiple projects) so that separate developers can work on individual solutions, while still having “visibility” into the other ones? For example, I want to be able to run and test a business module from Visual Studio directly (F5), but the login module is in a separate solution. Is there a way to divide website development like this?
If not, how can multiple developers work on separate projects that are in the same solution? (We are a tiny shop, and have not yet tried Team Foundation Services).
… Source control.
I read your question and the first thing that came to mind was “they’re trying to work on the same copy of the source code hosted on a network share”. Bad, bad, bad. Even if it’s a website, and thus to be accessed from one place in its normal running state, that’s not the proper way to develop it
Grab yourself a copy of Subversion or Mercurial, check the codebase into it and make sure everyone’s regularly committing their changes. Subversion Server itself is free from CollabNet; some of the tools used to provide GUI and IDE integration are not (but some good ones are; check out TortoiseSVN for general Windows Explorer-based repository actions, while AnkhSVN is a freeware plugin for Visual Studio allowing commits/updates from within the IDE).
Once you have this source control system set up, everyone “checks out” a working copy of the codebase onto their local machine, and can make all the changes to it that they want, then “checks in” those changes when they have a stable working version, which everyone else can then get by updating their own working copy. Obviously, this requires the developer machines to have enough muscle to run a rudimentary copy of the website on their own machine (most PCs from the last 4 years or so should have no problems running an instance of IIS, SQL Server Express, and an ASP.NET site with only the developer browsing it). To see what the latest working copy looks and acts like, you can regularly publish it to a staging environment mimicking your production servers (same distribution of services like IIS/SQL Server among different machines, probably lesser power unless you need to do load testing).
SVN handles multiple commits of the same file by “merging” changes, and there’s usually only a problem if two devs have modified the same line of code in different ways. If someone’s making large, sweeping changes to the codebase that may disrupt other users, but still wants to “commit” his working copy (generally a good thing, for backup purposes if nothing else), he can cut a “branch” based on the current source code, update from and commit to it, and then when he’s done, merge his changes back into the “trunk”.
Basically, every dev working on a project should be working in the same set of source code, which ideally would be a single solution that a developer could download from scratch from version control, open in VS, hit the “build” button and go. Your team should be communicating with each other about what projects and source files they’re working in, and should be regularly (like every hour or two) committing their changes and getting everyone else’s.
You can go the whole hog and implement a “continuous integration” server. On each checkin, this system will pull the latest source code and run a number of automated tasks, like running various tests/metrics, pushing to staging, etc. TeamCity is free if you install it on three or fewer “build agents” (each “build agent” can run a different suite of tests, or work based on a different commit). This typically has the greatest value when you are adhering closely to test-driven development practices; then the CI server runs the unit and integration tests to ensure the code does everything the developers think it should be, plus code coverage to ensure the rules are being followed and the code is being adequately exercised by the tests.
The idea of working in different solutions that expose different, but overlapping, projects is not a great one; I only ever saw that approach once as a strategy to reduce resource demands within a hosted virtual machine environment (loading a lot of projects, especially with a code analysis tool like ReSharper, can really tax an older system or an emulator/VPC setup).