在我的开发环境中，我有许多项目已经输出到dll的中央存储库。这是通过在项目的生成后事件命令行中添加xcopy命令来实现的。
XCOPY $(TargetDir)$(TargetFileName) C:\DEV\library /I /R /Y
我希望这种情况在dev模式下发生，但在teamcity服务器上时，我希望避免执行脚本。做这个最好的方法是什么？我将通过google和文档进行搜索，但希望其他人也以类似的方式使用了teamcity，并能提出实现的建议。
谢谢。
编辑：
xcopy应该将dll复制到一个中心文件夹（c:\dev\library）中，依赖于该文件夹的外围项目可以访问该文件夹。实际上，我已经从项目中删除了xcopy，因为我觉得使用它更多的是一种黑客行为，而不是帮助。感觉像是我把一个方形的钉子塞进了一个圆孔里。
最佳答案
据我所知，您使用xcopy将生成输出复制到外部文件夹，以便依赖解决方案可以将输出用作程序集引用。您已经正确地发现使用构建后事件和xcopy是错误的，因为它开始给您带来痛苦。我们在我们的api解决方案中有一个类似的目标，我将试着描述我们使用我们的解决方案所做的事情，但请记住，没有银弹，有时仍然需要妥协。
项目结构
项目结构不是visual studio中的结构，而是如何组织项目所需的源、库和其他外部项，此模式可以应用于大多数语言。项目结构应清晰，易于理解，并在所有项目之间保持一致。我使用的结构与许多开源项目一致，通常包括以下内容。
- root
|-- bin
|-- build
|-- lib
|-- src
|-- tools
根-根应该包含尽可能少的项目。
bin-bin是生成的输出应该去的地方。这可能只有当您有多个输出时才相关，如果您只有一个输出，比如一个web项目，它可以保持在原来的位置。我没有找到使用子文件夹进行调试和发布生成的理由。
构建-包含构建源代码、运行测试、代码覆盖率、代码分析、文档等的构建文件，如msbuild或nant脚本。
lib-包含项目输出所依赖的所有第三方库（外部或内部）。我通常为每个库使用子文件夹，但我不确定是否真的需要。
src-包含在所选ide中打开项目、编辑、生成和运行所需的所有文件。尽量保持结构的扁平化，没有必要让它变得过于复杂，因为其他开发人员不太可能像您那样有条不紊，您最终将项目放在错误的文件夹中。我做的最多的事情就是为所有的测试创建一个测试文件夹，但这并不是真正需要的。
工具-它包含生成所依赖的所有应用程序、程序集和外部文件，但源不应依赖其中任何一个，因为其依赖项依赖于库。
文件路径
项目中与的所有文件路径都应是相对的。一旦你开始使用绝对文件路径，你就会开始感到痛苦。如果开发人员的源代码位于不同的驱动器上，或者在运行项目的地方很难强制执行的生成服务器上，则会出现问题。
一般经验法则是项目应该是自包含的。在一个完美的世界中，不应该依赖于根文件夹之外的任何东西。有时这很困难，特别是在遗留项目上，或者在您有com、注册表或服务需求的地方，但是只要稍加考虑和修改，大多数需求都可以减轻。最终，您希望能够做到的是尽可能容易地将项目放到给定的计算机上并运行它。
生成输出
当我做一个api项目时，我把项目的输出放在上面提到的bin文件夹中。在生成后事件期间，您已经使用xcopy完成了此操作。这并不是说错了，因为它可以做你想做的事，但有了visual studio，有了更好的方法。如果转到projects属性的build部分，则可以更改输出的放置位置。请记住在更改之前选择所有生成配置。
从外部项目引用程序集
将api分离到其on解决方案中并将输出作为程序集引用而不是项目引用的原因之一是解决方案太大，或者您需要从多个解决方案中引用它们。如上所述，项目不应依赖于项目根目录以外的任何内容。因此，您不应该依赖于外部项目的输出，因此应该依赖于a.开发人员机器上存在的项目和b.位于正确的位置。
我有几种方法可以克服这个问题：
让api项目成为主项目内部的子项目，使用git的子模块或svn的外部模块。这在某种程度上是有效的，但是你需要采取一些预防措施，互联网上有丰富的知识。
将程序集添加到依赖项目的lib文件夹中，并将其视为第三方程序集，这就是它们的真正含义。
第二步是我的首选根目录，这可以在生成服务器上自动完成，也可以通过将生成服务器的输出复制到本地项目中手动完成。这完全取决于你是想要连续积分还是周期积分。