Organization of team work in Visual Studio

Tell me please if the following scenario is possible to implement with regular version of VS, I mean non team edition. First, our team is small enough about 10 developers and we using SVN as repository. Directory structure is relatively the same for every developer and for simplicity sake it looks like

Working\Deploy

Working\Sources

All projects resides in "Sources" directory and put output dll in "Deploy" dir.

So imagine, one is working on project "CoreLibrary" and output dll is CoreLibrary.dll and the second one working on "SomeLibrary" project, which use as reference CoreLibrary.dll. This is simplified situation, in real life this project could depend on numerous dll's which are subject of responsibility of other developers. In this scenario could be such situation when CoreLibrary is changed after SomeLibrary is compiled. And for example forgot to inform other developers to renew their references. And this changes make SomeLibrary project not compiling, but it would be know only at run time -) So to avoid this, we decided additionally to union all projects in one composite solution, where one project whould be referencing other - not it's output dll, so then if overall solution builds means all is compatible. But there is one problem - for this we need to change source project's dependency from dll to project. And if we open standalone project we wind out excalmation icon opposit this reference t开发者_开发问答hough, project is still able to be compiled.

I.e as conclusion - we have references between projects (each project - atomic functionality) through dlls. Atomicity leads to that when we change one "atom" we must check if this changes are compatible with other dependent atoms. This is more convenient to do having overall solution, where we load latest sources and try to compile. But, we need to change dependencies between projects from dlls to projects. This is seems to be not quite "right", as changes references in source standalone project. Making one big solution for all developers, forcing them recompile all sources, and not only his project is also bad.

I work with a situation fairly similar to this and the way that we handle it is each developer has their own solution and inside of the solution we add all of the projects that were using. This prevents the event when a project (or dll) gets changed that your project is dependent on from not seeing those changes, because you are referencing the older version. So anytime a file gets updated in a project that you are referencing and you build your solution, that file will be updated thus reflecting the changes. As far as I know this is the correct way to do this. When we try to use a solution out of our source control we tend to get referencing errors so that's why we've switched to just checking in the projects inside of the solution.