J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

Structuring Projects for Team Foundation Server

Structuring Projects for Team Foundation Server

  • Comments 14

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:

  1. Create a blank solution in VSTS
  2. Create a source folder on the file system (C:\MyApp\Source)
  3. Add new Web project (C:\MyApp\Source\MyAppWeb)
  4. 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

  1. Add your solution to source control
  2. Create a Main folder
  3. 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:

  1. Single solution
  2. Partitioned single solution
  3. 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. 

  • J.D. Meier has a good post on best practices for structuring your projects (ASP.NET and client) for best

  • In a new post by J.D. Meier he provides a link to a resource that I was not aware of, it' the patterns

  • In a new post by J.D. Meier he provides a link to a resource that I was not aware of, it' the patterns

  • We've taken the solution per system module approach. Unfortunately we are faced with two problems:

    1. 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.

    2. 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.

  • 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?

  • I manage the Config. Mgmt environment for my company's IT department.  We are a retail company at heart, so generally we develop many smaller line of business applications and have a few larger applications for things like a large hosted Loyalty system, etc.  One of the big problems I have with the Solution based approach is the difficulty to tightly manage versioning of shared assemblies (dll's).  

    In my opinion and the one I feel has been the most effective for us, is the idea that A) project references are bad if the two projects aren't being developed for a similar goal or logical project cycle, instead you should have versioned/static references and B) Solutions are a way for developer to organize the projects they are managing/developing for any particular release.  

    In our world, builds are initiated via Continuous integration and done at the project level.  People are able to rely on the version they have used for integration and certification testing, upgrading only when they are ready, not when someone has decided to check in a new change which has an impact they are not able to account for in their cycle.

    I would love to see the idea of user specific relative paths go away, cause this constantly causes developer headaches when they upgrade static versions.

  • J.D. Meier's blog is one i read fairly religously. Much I agree with, some things make me think and I

  • Jason2: I read a post on the Microsoft Connect Visual Studio bug site about embedded resources but it does not seem to apply for us. None of the projects involved have any resources that I could find and they were Class Libraries used by Windows Forms projects. The DLLs were loaded into devenv.exe's process space so I couldn't use SysInternal's Process Explorer to kill the handle.

    Ryan: We once had file references to compiled and MSI deployed DLLs for our shared projects but we found the turn-around for editing the shared projects and retesting the dependant projects rather tedious. We weren't too keen on trying to put binaries in source control either. Admittedly some of these problems would be solved by better tier/layer separation but you work with what you've got.

    We are working ever closer towards a build server and CI but there are always other priorities.

  • 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.

  • J.D. Meier on Structuring Projects for Team Foundation Server. Buck Hodges on Channel 9 interview...

  • This seems to be different than your guidance on CodePlex - where you recommend a local structure of C:\TeamProjects\MyApp1, C:\TeamProjects\MyApp2, etc.

    I've found that even if I create a website in C:\TeamProjects\MyApp1\MyWebsite1, 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?

  • 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'.

  • 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.

  • 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.

Page 1 of 1 (14 items)