What ASP.NET MVC project files should be kept in a repository?

Question

background:Me and my coworkers are working on asp.net mvc project ... we have a computer that works as a server which is where the project will be stored on... each of us has a copy of the project and we got tortoise cvs set up.

questions: when you want to commit something, what files exactly do you commit?.. asp.net reports many dll files, csproj files, cs and sln files that appear to be different from the server's.

Maybe my question is not the right one I should ask so I would appreciate some insight on whats the best approach for working in groups.

Thanks in advance

Answer 1

You really shouldn't check in anything that the project can generate itself. So no need to check in your bin or obj folders or anything like that, you also want to ignore any user preferences files.

This includes dlls, unless they are third party dlls, then you want to check them in to ensure everyone is working against the same version and this way you don't have to keep changing reference paths.

Answer 2

We keep everything except the BIN/OBJ folders in SVN. We have all third party Libraries in a seperate folder that they are referenced from.

Kindness,

Dan

Answer 3

The basic csproj file should be committed whenever you add or remove things from the project, to ensure that the project has all the correct files. The solution (sln) is a good one to commit, for the same reason, although I've also seen it done without. You'd also want to commit any cs files, naturally, as they're the main focus of things.

DLL files should only be committed if they're outside references--internal dlls to your project can be ignored, as they'll be built by each computer in turn. You also want to avoid .user files as unnecessary. Ignore the 'bin' and 'obj' folders for each directory, when it comes to commits as well.

Answer 4

I don't work in asp.net, so I will respond generically. We have a subversion code repository for our version system, cvs works well too. Developers retrieve all updated code from the repository, do work, make sure it's working correctly, do another get, re-compile, test, and then commit source code changes to the repository. On a regular basis you can have a tool or manually build the application from the repository, and deploy to a testing server. No compiled code should be placed in the repository.

-Jay

Answer 5

We use the following project structure in SVN (but this applies to CVS as well).

+ tags
+ branches
> trunk
  + build (build scripts)
  + lib (external libraries)
  > src (source code)    
   >> Organization.App (solution name)
     >> Organization.App.Core (code library)
        + Config
        > Domain
          > Model
          > Persistence
          > Queries
          > Services
        > Persistence
        > Services
     >> Organization.App.Web (mvc web app)
        > Assets
          + Images
          + Scripts
          + Stylesheets
        + Controllers
        + Views
        + ViewModels

We put all our 3rd party dependencies into the lib folder. Including MVC, which can be bin deployed. See this article by Phil Haack. So when a new developer comes online all they have to do it check out the trunk, and they should have everything they need to get going. Using a CI server is a cinch because all of the projects dependencies are encapsulated by the lib folder and all of the visual studio projects make reference to those dll's in that lib folder.

Does that make sense?

Never mind the core folder and the web folder. That's just how we structure our projects within the solution. But that's a whole other conversation. :)

Answer 6

If you are using a database change management tool, such as Tarantino, then you will also want to check in SQL change scripts and/or populate scripts. We have a folder in our 'Core' solution where we keep these, ie 'Core/Database/Updates'. We use SQL Compare to find changes in our database then we check in those SQL change scripts so that other developers can just run them locally. We have a nant task setup to call on Tarantino to sync up the other build environments (Dev, QA) and run any new change scripts.