Structuring Projects for Team Foundation Server
I've seen a few customers asking how to structure projects for Team Foundation Server. I don't blame them. Finding a structure that works well for you can be tricky, particularly if you don't have the benefit of hind-sight or a bunch of reference examples to draw from.
My team spent some time this past week evaluating various approaches and lessons learned from various projects We boiled it down to something that seems to be working well, and distills what's worked for some teams. With the caveat that we're still evaluating, here's what we learned ...
Solution
Local File System
C:\MyApp
\MyApp.sln
\Source
\MyAppWeb
\ClassLibrary1
Source Control (Team Foundation Server)
/Main
/Build
/Docs
/Source
/MyApp
MyApp.sln
/Source
/MyAppWeb
/ClassLibrary1
/UnitTests
/MyAppWebTests
/ClassLibrary1Tests
/Tests
Key points
Here's a few highlights about this approach:
- On the client side, we explicitly creat our solution file up front instead of rely on defaults
- The project folder containts one master solution.
- The project has source and unit tests. Loading the solution for the project, loads the source and unit tests
- The Main folder in TFS holds the project assets (Build, Docs, Source, Tests). Using Main lets us create other folders for potential branches (Development, Production, Maintenance ... etc.)
Repro Steps
Here's a brief walkthrough to test using a file-based Web:
- Create a blank solution in VSTS
- Create a source folder on the file system (C:\MyApp\Source)
- Add new Web project (C:\MyApp\Source\MyAppWeb)
- Add new Class Library (C:\MyApp\Source\ClassLibrary1)
Verify your folder structure on your File System:
C:\MyApp
\MyApp.sln
\Source
\MyAppWeb
\ClassLibrary1
Adding to TFS
- Add your solution to source control
- Create a Main folder
- Create a Source folder beneath Main
Verify your folder structure in Source Control Explorer
/Main
/Source
/MyApp
/MyApp.sln
/Source
/MyAppWeb
/ClassLibrary1
More Information
You should know that while I talked through the single solution scenario, there are additional patterns. Here's the key patterns we see:
- Single solution
- Partitioned single solution
- Multi-solution
You can find more on these patterns at Team Development with Visual Studio .NET and Visual SourceSafe. You should also know that we have a few How Tos on structuring your projects coming your way. We'll post them to our VSTS Guidance Project.
Share Your Story
If you've got lessons learned the hard way or practices to share, I'd like to hear them. Now's a great time to share since we're actively building guidance. Either comment here or write a post and leave a link.
Comments
Anonymous
March 13, 2007
J.D. Meier has a good post on best practices for structuring your projects (ASP.NET and client) for bestAnonymous
March 13, 2007
In a new post by J.D. Meier he provides a link to a resource that I was not aware of, it' the patternsAnonymous
March 13, 2007
In a new post by J.D. Meier he provides a link to a resource that I was not aware of, it' the patternsAnonymous
March 14, 2007
We've taken the solution per system module approach. Unfortunately we are faced with two problems:
- We are regularly plagued by class library DLLs being locked by Visual Studio between builds in the IDE. The only way to unlock is restart Visual Studio. Seems neither us nor MS can positively identify the conditions that cause this.
- We haven't found a good folder structure for easily branching a module in TFS and the projects it includes that are shared by other modules.
Anonymous
March 14, 2007
1 - Do you use resources embedded within a project? We started having a similar problem soon after we began storing friendly user error messages as a resource within our library assembly. One DLL was locked by the w3wp process after running the app. I never had time to diagnose whether it was the problem, but it is something to suspect : the ResourceManager loads from the assembly, and the assembly is being locked. Maybe MS can focus on that area?Anonymous
March 14, 2007
The comment has been removedAnonymous
March 14, 2007
J.D. Meier's blog is one i read fairly religously. Much I agree with, some things make me think and IAnonymous
March 14, 2007
The comment has been removedAnonymous
March 14, 2007
Hey Jason (the first one) - you might have a scenario for "multiple solution files and flat projects": http://blogs.msdn.com/jmeier/archive/2007/03/15/multiple-solutions-and-flat-projects.aspx (create a scaled down repro and test for your scenario) You have a few branching strategies to choose from. Without seeing your scenario, it might be more helpful if I point you to our "Branch/Label/Merge" section in our "Source Control Practices at a Glance": http://www.codeplex.com/VSTSGuidance/Wiki/View.aspx?title=Source%20Control%20Practices%20at%20a%20Glance&referringTitle=Home Keep in mind we're actively sweeping these with new learnings this week and next.Anonymous
March 15, 2007
J.D. Meier on Structuring Projects for Team Foundation Server. Buck Hodges on Channel 9 interview...Anonymous
March 16, 2007
This seems to be different than your guidance on CodePlex - where you recommend a local structure of C:TeamProjectsMyApp1, C:TeamProjectsMyApp2, etc. I've found that even if I create a website in C:TeamProjectsMyApp1MyWebsite1, the project file is added to the VS directory in MyDocuments, and when added to source control, the project file isn't added. This of course makes it hard to share with other devs. How can I override that?Anonymous
March 16, 2007
Oh Geez. I see now that there is no web project file for Websites. OK, so I how do I arrange the website so that it can be easily be deployed to a dev, test, and production servers? Remember, it's not a developer who's doing the deployment - it most likely isn't even someone that has VS installed. Yet the copy and publish tools seem geared for an "enterprise" where the developer is a domain admin, which violates best practices for LUA. There is no help documentation on the Web Setup project, which might be what I'm looking for. It looks like all of the samples and help documentation is geared toward someone who wants to deploy straight to production and ftp back and forth. It seemed easier when it was complicated! aside Why is ASP.Net 2.0 geared more toward the blog, drag 'n drop crowd? Isn't Expression or one of those products better for them? It's now so much harder to manage actual enterprise web applications in VS. Sigh. Sorry to vent, but this one has been bugging me ever sinced I rolled up my sleeves and started digging into ASP.NET 2.0. Your blog is great, keep it comin'.Anonymous
March 16, 2007
Hey Brian! Yes, the guidance is slightly behind the blog, until we finish our sweep. We'll also be adding new source control How Tos, Guidelines and Explained articles, that walk through specific steps and details. I don't have a great answer for you on the deployment yet -- not because there isn't one, but because our team hasn't focused there yet. Next week, we begin drilling down on build/deployment scenarios. We'll be looking at dev and test environment topologies, internet access, continuous integration, nightly builds, ... etc. If I understand you correctly, your key issues sounds like ... what are proven practices for a network user (non-admin) to deploy to a staging or production server, where VSTS is not-installed? I'll make sure that scenario is in our test matrix (we build guidance by executing customer scenarios, evaluating aproaches, and drawing from empirical references). Meanwhile, you might try putting your question out to the forums because I am sure you are not alone.Anonymous
October 18, 2007
We use pretty similar structure. But currently we have a problem with master solution because it includes about 70 projects and Visual Studio works very slow. What would you recommend to do in such situations.