Question

我在VS2010的自动项目结帐（文件 - ＆gt;源代码管理 - ＆gt;从源代码管理中打开）行为方面遇到了一些麻烦。问题是关于Microsoft Unity，但通常是关于构建共享依赖关系。

假设这个TFS结构

$/                                                
    Project1/
    Project2/
    Microsoft/
        UnityQuickStarts/
        UnitySource/
            Lib/
            Source/
                Common/
                Unity/
                    Src/
                    Tests/
                Unity.Configuration/
                Unity.Interception/
                Unity.Interception.Configuration/
                Unity.Silverlight/

假设Project1.sln中有Project1.vbproj和$/Project1，其项目引用为$/Microsoft/UnitySource/Source/Unity/Src/Unity.2010.csproj。

当我请求VS2010从Source Control打开Project1.sln解决方案时，它设法获得Unity项目，但只是其中的一部分。具体来说，它没有意识到$/Microsoft/UnitySource/Lib项目中存在二进制依赖关系，并且它没有意识到$/Microsoft/UnitySource/Source/Common中存在所需的代码文件。它们位于Unity项目根目录之上。

我得到的文件夹结构究竟取决于我是将Unity项目从源代码控制添加到现有解决方案还是打开整个解决方案。

使其工作的唯一方法是手动将$/Microsoft/UnitySource项目添加到工作区并“获取最新”。从那里我可以将Unity.2010.csproj项目添加到解决方案中，每个人都很高兴，至少在我需要再次获得项目之前，当TFS没有获得所有文件时。

那么，Micrsoft的模式和实践团队是否创建了一个与TFS / VS2010不兼容的项目结构，或者更可能的是，我是否错误地构建了项目？ Project1和Project2都可以使用Unity，因此将它放在两个项目下都不合适。

感谢。

更新：完善问题：Unity的整体解决方案文件为$\Microsoft\UnitySource\Source\Unity.2010.sln。如果我要求VS2010从源代码管理中打开该解决方案，它只会获得Source项目及其子项。具体来说，$\Microsoft\UnitySource\Lib项目不存在，因此Unity缺少其依赖项之一，Microsoft.Practices.ServiceLocator.dll。

TFS或VS2010是否有办法“管理”这些外部依赖项？我们是否必须将这些共享依赖项置于其他项目的上方/旁边（p＆amp; p团队使用Unity的方式），并通过手动分配正确的文件夹来处理TFS / VS2010没有“做正确的事”的事实映射？

将第三方代码放在Team Foundation Server中的位置

0 个答案: