在 Visual Studio 中组织团队工作
请告诉我以下场景是否可以用常规版本的 VS 实现，我指的是非团队版本。 首先，我们的团队规模很小，大约有 10 名开发人员，并且我们使用 SVN 作为存储库。对于每个开发人员来说，目录结构相对相同，为了简单起见，它看起来像
Working\Deploy
工作\源
所有项目都驻留在“源”目录中，并将输出 dll 放在“部署”目录中。
想象一下，一个正在处理项目“CoreLibrary”，输出dll是CoreLibrary.dll，第二个正在处理“SomeLibrary”项目，它用作参考CoreLibrary.dll。这是简化的情况，在现实生活中，该项目可能依赖于许多由其他开发人员负责的 dll。在这种情况下，当编译 SomeLibrary 后更改 CoreLibrary 时，可能会出现这种情况。例如，忘记通知其他开发人员更新他们的参考资料。此更改使 SomeLibrary 项目无法编译，但只有在运行时才会知道 -) 因此，为了避免这种情况，我们决定另外将所有项目合并到一个复合解决方案中，其中一个项目应该引用其他项目 - 而不是它的输出 dll，因此，如果整体解决方案构建意味着所有项目都是兼容的。但有一个问题 - 为此我们需要将源项目的依赖关系从 dll 更改为项目。如果我们打开独立项目，我们会在该引用对面看到感叹号图标，但项目仍然可以编译。
即作为结论 - 我们通过 dll 在项目之间进行引用（每个项目 - 原子功能）。原子性导致当我们改变一个“原子”时，我们必须检查这一改变是否与其他依赖原子兼容。这对于整体解决方案来说更方便，我们加载最新的源代码并尝试编译。但是，我们需要将项目之间的依赖关系从 dll 更改为项目。这似乎不太“正确”，因为更改了源独立项目中的引用。 为所有开发人员制定一个大解决方案，迫使他们重新编译所有源代码，而且不仅他的项目也很糟糕。
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 though, 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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我处理的情况与此非常相似，我们处理它的方式是每个开发人员都有自己的解决方案，并且在解决方案内部我们添加所有正在使用的项目。这可以防止您的项目所依赖的项目（或 dll）发生更改时看不到这些更改，因为您引用的是旧版本。因此，每当您引用的项目中的文件更新并构建解决方案时，该文件都会更新，从而反映更改。据我所知，这是正确的方法。当我们尝试使用源代码控制之外的解决方案时，我们往往会遇到引用错误，因此我们转而只检查解决方案内的项目。
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.