We are building a very large enterprise web application using Visual Studio 2013 ASP.net MVC 5.
We are using TFS 2013.
We create one team project in the TFS.
Now in visual studio, we need best practice or guidelines to structure our application that contains about 14 modules.
1) create one really large solution containing all projects for all modules of the application. 2) create many smaller solutions with fewer projects in each.
Thank you.
Your choice will depend on one factor:
One solution to rule them all, because otherwise your team mates would need to recompile parts of your entire project in different Visual Studio instances, and this can decrease productivity of your team, and it can lead to errors since more than a team mate will miss to recompile something and he/she'll get into big troubles until someone would tell him/her: just recompile X solution to get this working (or it can take to a documentation nightmare...).
Many solutions for the same main solution. Imagine that front-end team needs to consume infrastructure and domain code, and they aren't allowed to edit that last code base. Thus, front-end team would be able to edit front-end code base, and the backend team the rest of it.
Anyway, this implies that you'll need to configure TFS continous integration with TFBuild in order to drop latest and fresh backend built code in some network share, so front-end code will be able to binarily-reference these assemblies.
In other words: if there's a framework team and application team, maybe this approach makes sense. Otherwise, it'll be better to go with the first approach.
Anyway, a solution composed by 30 projects it's not a big solution! I wouldn't pay too much attention to this, and I would go with A. approach...
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments