C# teamcity visual-studio-2010 projects-and-solutions

C#、TeamCity - 避免 TeamCity 服务器上的构建后事件

发布于 2024-09-28 18:26:25 字数 433 浏览 0 评论 0原文

我有许多项目已输出到我的开发环境中的 DLL 中央存储库。这是通过将 XCopy 命令添加到项目的构建后事件命令行中来实现的。

XCOPY $(TargetDir)$(TargetFileName) C:\DEV\library /I /R /Y

我希望这种情况在开发模式下发生，但在 TeamCity 服务器上时我想避免执行脚本。这样做的最佳方法是什么？我将通过 Google 和文档进行搜索，但希望其他人以类似的方式使用 TeamCity，并可以建议如何实现它。

谢谢。

编辑：

XCopy 应该将 dll 复制到依赖于它们的外围项目可以访问的中央文件夹（C:\DEV\library）中。事实上，我已经从项目中删除了 xcopy，因为我觉得它更像是一种黑客攻击，而不是对使用它的帮助。感觉就像我正在将一个方钉强行插入一个圆孔中。

原文

I have a number of projects which I have outputting to a central repository of DLLs in my development environment. This is achieved by adding an XCopy command into the Post-build event command line of the project.

XCOPY $(TargetDir)$(TargetFileName) C:\DEV\library /I /R /Y

I want this to happen in dev mode but when on the TeamCity server I want to avoid the script from being executed. What is the best way of doing this? I am going to search through Google and the documentation but was hoping that others have used TeamCity in a similar way and could advise how it is achieved.

Thanks.

EDIT:

The XCopy is supposed to copy the dll's into a central folder (C:\DEV\library) that the peripheral projects that are dependant on them can access. I have in fact removed the xcopy from the projects because I felt it was more of a hack than a help to use it. Felt like I was forcing a square peg into a round hole.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

将军与妓 2024-10-05 18:26:25

据我了解，您正在使用 XCopy 将构建输出复制到外部文件夹，以便依赖的解决方案可以使用输出作为程序集引用。您正确地发现使用构建后事件和 XCopy 是错误的，因为它开始给您带来痛苦。我们在 API 解决方案中也有类似的目标，我将尝试描述我们的解决方案，但请记住，没有灵丹妙药，有时仍然需要妥协。

项目结构

项目结构不是 Visual Studio 内的结构，而是如何组织项目所需的源、库和其他外部项目，此模式可以应用于大多数语言。项目结构应该干净、易于理解并且所有项目之间保持一致。我使用与许多开源项目一致的结构，通常由以下内容组成。

- root
|-- bin
|-- build
|-- lib
|-- src
|-- tools

root - 根应包含尽可能少的项目。
bin - bin 是构建的输出应该存放的位置。这可能仅在您有多个输出时才有意义，如果您只有一个输出（例如 Web 项目），它可以保留在原来的位置。我发现没有理由使用子文件夹进行调试和发布版本。
build - 包含构建文件，例如 MSBuild 或 NAnt 脚本，用于构建源代码、运行测试、代码覆盖率、代码分析、文档等。
lib - 包含所有第三方项目输出所依赖的外部或内部库。我通常为每个库使用子文件夹，但我不确定是否真的需要这样做。
src - 包含在您选择的 IDE 中打开项目、编辑、构建和运行所需的所有文件。尽量保持这里的结构尽可能平坦，没有必要试图让它变得太复杂，因为其他开发人员不太可能像您一样有条不紊，并且您最终会将项目放在错误的文件夹中。我做的最多的事情就是为所有测试创建一个测试文件夹，但即使这也不是真正需要的。
工具 - 这包含构建所依赖的所有应用程序、程序集、外部文件，但源不应依赖于其中任何一个，因为它依赖于库。

文件路径

项目中的所有文件路径都应该是相对的。一旦您开始像示例中那样使用绝对文件路径，您就会开始感到痛苦。在开发机器上会出现问题，因为开发人员的源代码位于不同的驱动器上，或者在构建服务器上，很难强制执行项目的运行位置。

一般的经验法则是项目应该是独立的。在完美的世界中，不应该依赖于根文件夹之外的任何内容。有时这很困难，特别是在遗留项目或有 com、注册表或服务需求的情况下，但只要稍加思考和返工，大多数问题都可以得到缓解。最终，您希望能够尽可能轻松地将项目放到给定的机器上并运行它。

构建输出

当我执行 API 项目时，我将项目的输出放入上面提到的 bin 文件夹中。您已在构建后事件期间使用 XCopy 完成了此操作。这本身并没有错，因为它会做你想做的事，但使用 Visual Studio 有更好的方法。如果您转到项目属性的构建部分，您可以更改输出的放置位置。请记住在更改之前选择所有构建配置。

从外部项目引用程序集

将 API 分离到其解决方案中并将输出作为程序集引用而不是项目引用进行引用的原因之一是解决方案变得太大或者您需要从多个解决方案中引用它们。如上所述，项目不应依赖于项目根之外的任何内容。因此，您不应该依赖于外部项目的输出，而是依赖于 A. 项目存在于开发人员计算机上以及 B. 位于正确的位置。

我有几种方法可以克服这个问题：

使用 Git 的子模块或 SVN 的外部之类的东西，让 API 项目成为主项目内的子项目。这在某种程度上有效，但您需要采取一些预防措施，互联网上有丰富的知识。
将程序集添加到依赖项目的 lib 文件夹中，并将它们视为第三方程序集，这才是它们真正的样子。

第二步是我首选的根目录，这可以在构建服务器上自动完成，也可以通过将构建服务器的输出复制到本地项目中来手动完成。这完全取决于您想要持续集成还是周期性集成。

As far as I understand it you were using XCopy to copy the build output to an external folder so that dependent solutions could use the output as assembly references. You have rightly found that using post build events and XCopy is wrong as it is starting to cause you pain. We have a similar goal in our API solutions and I will try and describe what we do with ours but bare in mind that there is no silver bullet and compromises are sometimes still required.

Project structure

The project structure is not the structure within Visual Studio but how you organise the source, library and other external items that the project requires, this pattern could be applied to most languages. The project structure should be clean, easy to understand and consistent between all projects. I use a structure consistent with a number of open source projects and normally consists of the following.

- root
|-- bin
|-- build
|-- lib
|-- src
|-- tools

root - The root should contain as few items as possible.
bin - The bin is where the output of the builds should go. This is probably only relevant when you have multiple outputs, if you have only one output such as a web project it can stay where it is. I have found no reason to use a sub folder for debug and release builds.
build - Contains build files such as MSBuild or NAnt scripts for building the source, running tests, code coverage, code analysis, documentation, etc.
lib - Contains all the third party libraries, either external or internal, that the project output is dependent on. I usually use sub folders for each library but I am not sure if I really need to.
src - Contains all the files required to open a project, edit, build and run within your chosen IDE. Try to keep the structure in here as flat as possible, there is no point trying to make it too complicated as other developers are unlikely to be as methodical as you and you will end up with projects in wrong folders. The most I do is to create a test folder for all the tests but even this is not really required.
tools - This contains all the applications, assemblies, external files that the build is dependent on but the source should not be dependent on any of it as its dependencies are on the libraries.

File paths

All file paths with in the project should be relative. As soon as you start to use absolute file paths as you have in the example you will start to feel pain. Problems will arise on development machines where the developer has his source on a different drive or on the build server where it is much harder to enforce where the project is run from.

The general rule of thumb is that a project should be self contained. In a perfect world there should be no dependencies on anything outside of the root folder. Sometimes this is hard, especially on legacy projects or where you have com, registry or service requirements but with a little thought and reworking most of these can be mitigated. Ultimately what you want to be able to do is make it as easy as possible to get a project onto a given machine and run it.

Build output

When I do an API project I have the output of the projects put into the bin folder I mentioned above. You have done this using XCopy during the post build event. This is not wrong per say as it will do what you want but with Visual Studio there is a better way. If you go to the build section of a projects property you can change where the output is put. Remember to select all build configurations before changing it.

Referencing assemblies from external projects

One of the reasons for separating out an API into its on solution and referencing the output as assembly references instead of project references is because either the solution has become too big or that you need to reference them from multiple solutions. As stated above a project should not be dependent on anything outside of the project root. Therefore you should not be dependent of the output of an external project and therefore be dependent on A. the project being present on the developers machine and B. being in the correct location.

There are a couple of ways I overcome this:

Have the API project be a sub project inside the main projects using something like Git's Sub Modules or SVN's Externals. This works to some degree but there are some precautions you will need to take, there is a wealth of knowledge on the internet.
Add the assemblies to the lib folder of the dependent projects and treat them as third party assemblies, which is what they really are.

Step two is my preferred root, this can either be done automatically on the build server or manually by copying the output from the build server into the project locally. It all depends on whether you want to have continuous integration or periodic integration.

回复收藏 0 原文