Team Development with Visual Studio .NET
-
(Sorry about the length of what follows but I'm struggling with this issue and am hoping to see how other orgranizations are developing with VS.NET) Anybody out there read the series of white papers on MSDN entitled Team Development with Visual Studio .NET and Visual SourceSafe[^]? At work we are setting up the build and development environment for a new product and are running up against some roadblocks. Our project is a fairly complex enterprise desktop application that is going to require the use of C#, managed C++, ATL COM, MFC COM and even some good old fashioned C dlls. Once an application moves past some level of complexity (as ours has), we are coming to the conlcusion that VS.NET's capabilities for solution management begins to break down. The white papare suggests three approaches for organizing solutions:
- A Master Solution. This is a single SLN containing all projects. This quickly becomes unwieldy once you get past about 10 projects or so.
- A Partitioned Solution. This retains a master SLN file for integration building, but also suggests multiple smaller solutions that are more manageable for development work. We ruled this out, as it requires that project settings be maintained in two places (the development solutions and the master solution)
- Multiple Solutions. In this scenario you do away with the Master SLN and maintain a SLN file for each part of the app.
The is the approach we are going with is based on option 3, with each solution being roughly analagous to the UML concept of a Package. Unfortunately there seem to be some limitations to VS.NET that make this more work than it should be:
- When you start an assembly in the debugger, managed C# assemblies get copied to the right place, but their static dependencies (things labeled as content in the project) do not get copied along with them. So if managed assembly A needs XMLFile1.xml, XMLFile1.xml needs to manually copied to the debug targets build location.
- Unmanaged C++ dlls never get copied outside of their build directory even if managed assemblies are dependent upon them (and further more even if these static dlls are marked as content of the managed project).
- Project references work fine within