在解决方案树之间共享项目的最佳实践（MSVS 2008 和 MSVS 2010）
我们有 50 多个项目，分为由 TFS 管理的 2 个解决方案树（版本：Visual Studio 2008 / TFS RTM (9.0.21022.8)）。
30 多个项目是 Visual Studio 2008 项目，其他项目是 Visual Studio 2010
新项目通过引用二进制文件使用一些旧程序集。
在开发新项目期间，我们必须对旧程序集进行更改，因此我们必须同时打开 2 个 MSVS 实例。
有没有办法在两个不同的工作室解决方案树之间使用 TFS 共享可编译源？或者我们应该将 2008 年的解决方案树升级到 2010 年？ TFS 2008 是否支持共享项目（或者可能也必须升级）？
先感谢您！
We have 50+ projects divided into 2 solution trees managed by TFS (Version: Visual Studio 2008 / TFS RTM (9.0.21022.8)).
30+ projects are Visual Studio 2008 projects and others are Visual Studio 2010
New projects use some older assemblies via references to binaries.
During developing new projects we have to make changes into older assemblies so we have to keep 2 MSVS instances opened simultaneously.
Is there a way to share compilable sources with TFS between two different studios solution trees? Or shall we upgrade 2008 solution tree to 2010? Does TFS 2008 support shared projects (or may be it have to be upgraded too)?
Thank you in advance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
安德鲁：
首先，我们违反了一些“最佳实践”来实现这一目标，但实用主义是最佳实践与现实世界的结合。
我们所做的是：
它最终是这样的：
$/ProjectA/Main/Localbin/SharedBin分支到$/ProjectB/Main/SharedBin和$/ProjectB/Dev /Sharedbin（以及$/ProjectC、$/ProjectD等中的等效文件夹）。我们仅在成功进行 MAIN 构建时才进行此共享，并且该构建不仅负责合并到其他 MAIN 分支项目，还负责合并到 DEV 分支项目，因此它们是最新的。
我们曾经考虑过在成功构建后将二进制文件复制到共享网络位置，并制定一个约定来引用该网络共享中的这些二进制文件，但这个过程现在对我们来说效果很好，我们不愿意此时对其进行更改（目前正在发生更重要的事情）。
这是很难在帖子中完全描述的事情之一，所以如果您还有其他问题，我很乐意尝试回答它们。
顺便说一句，我们的解决方案是在 TFS2008 下构建并运行的，包含数千个项目文件，可能还有数百万行代码。由于合并，它确实增加了构建时间，并增加了存储库中使用的空间量，但到目前为止，两者都是可以管理的。
Andrew:
First off, we violate a couple of "best practices" to accomplish this, but pragmatism is where best practice meets the real world.
What we do is this:
It winds up being something like this:
$/ProjectA/Main/Localbin/SharedBinis branched to$/ProjectB/Main/SharedBinand$/ProjectB/Dev/Sharedbin(as well as the equivalent folders in$/ProjectC,$/ProjectDet cetera).We only do this sharing when we have a successful MAIN build, and the build is responsible for merging not only to the other MAIN branch projects, but also to the DEV branch projects, so they are up to date.
We've toyed around with the idea of coping the binaries to a shared network location after successful build, and having a convention to reference those binaries in that network share, but this process is working well for us today, and we're loathe to make changes to it at this point (more important things happening for now).
This is one of those things that's hard to fully describe in a posting, so if you have further questions, I'd be happy to try to answer them.
BTW, our solution was built and is running under TFS2008 with thousands of project files, and likely millions of lines of code. It does increase the build time due to the merge and increases the amount of space used in your repository, but both have been manageable thus far.