有没有办法只安装 tfs 命令行？
我有一个为 Java 和 .NET 项目配置的 CI 构建服务器，并且正在尝试将一个新项目集成到该服务器。不幸的是，该项目使用 TFS (2008) 作为其 SCM。
在此之前，我知道 TFS 提供构建功能，但我们正在尝试标准化构建基础设施，第一步是通过相同的 Web 服务（本例中为 Jenkins）构建所有项目。
我需要将 TFS 安装到构建服务器，因此我下载了 TeamExplorer 客户端，这是一个大小不到 400Mb 的 ISO。当我尝试从 ISO 安装时，它不提供可选的安装组件，并提供了将安装的大量组件（据我所知，大多数组件永远不会在此服务器上使用）。
- Microsoft Visual Studio 2008 Shell（集成模式）
- Microsoft Visual Studio Tools for Microsoft Office system（版本 3.0 Runtime）
- Microsoft Visual Studio 2005 Tools for the 2007 Microsoft Office System Runtime
- Microsoft Document Explorer 2008
- Microsoft Visual Studio 2008 Team Explorer
- Microsoft Office System 2003 Primary Interop 安装完整的 Visual Studio UI 和所有附带的
东西似乎太过分了，因为我只会调用 CLI TFS 客户。这对于 CLI 实用程序来说是必需的吗？
是否可以只获取命令行 TFS 所需的程序集？或者是否可以仅从 ISO 安装 CLI？
我知道这里有一个类似的问题， ijprest 的答案中为工作命令行 TFS 复制的最小文件列表，但我不想安装 hack。我更喜欢受支持的安装，这样将来不会造成混乱。
[编辑]
根据收到的几个答案，我将解释环境和推理。
构建服务器本身是Windows 2008服务器，但我无法通过TFS构建，因为我们正在尝试创建一个统一的CI系统来处理多个项目。
有些项目是.NET，有些是Java。有些托管 (SCM) 在 Subversion 上，有些托管在 ClearCase 上。这个新项目托管在 TFS 上（到目前为止，共有 6 个项目中的 1 个），因此 TFS 在这里只是少数。
从政治上讲，我们不能强制项目使用一套工具。然而，我们希望拥有一个构建点能够温和地推动项目采用更统一的方法（或者至少推动项目领导在购买新工具/框架/等之前相互“交谈”） 因此，
构建服务器需要能够将源代码从 SCM 拉到“构建”区域，然后执行构建（通过 Ant、Maven、NAnt、MSBuild、Grdle 等），但重要的是：
- 构建是自动开始的源代码更改时（基于轮询 SCM）
- 构建系统将从 SCM 中提取源代码，无需人工交互。
- 构建将通过约定进行，或者（至少）通过基于 SCM 的脚本进行。 xml、makefile 等）。重要的是再次没有人际交互。
I have a CI build server configured for Java and .NET projects and am trying to integrate a new project to the server. Unfortunately, this project uses TFS (2008) for its SCM.
Before it's said, I know TFS provides build capability, but we are trying to standardize on build infrastructure and the first step is having all projects built through the same web services (Jenkins in this case).
I need to install TFS to the build server, so I downloaded the TeamExplorer client, an ISO just under 400Mb in size. When I tried installing from the ISO, it doesn't offer optional install components, and comes up with a large list of components it will install (most will never be used on this server, AFAIK).
- Microsoft Visual Studio 2008 Shell (integrated mode)
- Microsoft Visual Studio Tools for Microsoft Office system (version 3.0 Runtime)
- Microsoft Visual Studio 2005 Tools for the 2007 Microsoft Office System Runtime
- Microsoft Document Explorer 2008
- Microsoft Visual Studio 2008 Team Explorer
- Microsoft Office System 2003 Primary Interop Assemblies
It seems very much overkill to install the full Visual Studio UI, and all attendant stuff as I will only ever be calling the CLI TFS client. Is that all necessary for the CLI utility?
Is it possible to get just the assemblies required for command line TFS? Or is it possible to install only the CLI from the ISO?
I know there is a similar question here, with a list of the minimum files to copy for a working command line TFS in ijprest's answer, but I don't want to install a hack. I'd prefer a supported install that won't cause confusion in the future.
[Edit]
Based on a couple of answers that came in, I'll explain the environment and reasoning.
The build server itself is a Windows 2008 server, but I can't build through TFS, because we are trying to create a unified CI system that will handle multiple projects.
Some projects are .NET, some Java. Some are hosted (SCM) on Subversion, some on ClearCase. This new project is hosted on TFS (so far 1 project out of 6), so TFS is in the minority here.
Politically, we cannot mandate that projects use a single set of tools. However, we're hoping that having a single build point will gently push projects into a more uniform approach (or at least push project leadership into 'talking' to each other before purchasing new tools/frameworks/etc.
So, the build server will need to be able to pull source from SCM onto a 'build' area, then perform the build (through Ant, Maven, NAnt, MSBuild, Grdle, whatever), but the important things are:
- The build is kicked off automatically based upon source changes (based upon polling the SCM)
- The build system will pull the source from SCM with no human interaction.
- The build will occur via convention, OR (at least) via SCM based scripts (build.xml, makefiles, etc.). The important thing is again no human interaction.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
从技术上讲，是的，这是 Microsoft 支持的唯一安装
tf.exe命令行客户端的方法。命令行客户端仅与 UI 组件捆绑在一起的一个重要原因是命令行客户端实际上确实会引发 UI（除非您使用
/noprompt标志。）这是这样的：您基本上可以构建一些简单的脚本，这些脚本实际上非常强大，并且能够提供交互式工作区管理、冲突解决等。显然，您不会在构建环境中从中受益，但这就是它以这种方式捆绑的原因 -命令行客户端确实需要对 UI DLL 的依赖。如果您想在非 Windows 架构上构建 Jenkins，可以使用 Team Explorer Everywhere 命令行客户端，它是 Java 中
tf的跨平台实现。它具有与 tf.exe 大部分相同的功能，并且在大多数情况下是参数兼容的，旨在为构建提供可编写脚本的跨平台解决方案。 Jenkins TFS 插件确实支持 Team Explorer Everywheretf命令行客户端。但是，如果您要在 Windows 上使用 TEE 版本的tf命令行客户端，我们将不提供对此安装的支持。微软也不支持您提到的简单复制必要的程序集的答案。
Technically, yes, that's the only Microsoft-supported way to install the
tf.execommand-line client.One of the big reasons that the command-line client only comes bundled with the UI components is because the command-line client actually does raise UI (unless you use the
/nopromptflag.) This is so that you can basically build some easy scripts that are actually very powerful and have the ability to provide interactive workspace management, conflict resolution, etc. Obviously you won't benefit from this in your build environment, but that's why it's bundled the way it is - the command-line client does take a dependency on the UI DLLs.If you wanted to do a Jenkins build on a non-Windows architecture, you could use the Team Explorer Everywhere command-line client, which is a cross-platform implementation of
tfin Java. It has most of the same functionality oftf.exe, and is argument-compatible in most cases, and was intended to provide a scriptable cross-platform solution for build. The Jenkins TFS plug-in does support the Team Explorer Everywheretfcommand-line client. However, if you were to use the TEE version of thetfcommand-line client on Windows, we would not provide support for this installation.Microsoft would also not support the answer you mentioned of simply copying the necessary assemblies over.
您发布的组件列表不包括“完整”的 VS UI。 Visual Studio 被组织为 shell 加插件。在本例中，它正在安装 shell 和一个插件（Team Explorer）。
您最终得到的结果无法创建应用程序，也无法执行除充当 TFS 的 GUI 客户端之外的任何操作。它不会自动赋予人们进行构建的能力 - 这是通过您在 TFS 中分配给他们的权限赋予他们的。如果没有人有能力创建构建定义或运行构建定义，那么就不会有构建。
您也可以根本不安装构建服务。
The list of components you posted does not include a "full" VS UI. Visual Studio is organized as a shell plus plugins. In this case, it's installing the shell, and one plug-in (Team Explorer).
What you wind up with has no ability to create applications, or do anything other than act as a GUI client to TFS. It does not automatically give people the ability to do builds - that is given to them by the permissions you assign them in TFS. If nobody has the ability to create build definitions, or to run build definitions, then there will be no builds.
You can also simply not install the build service at all.