防止 Visual Studio 2010 安装项目将文件添加到源代码管理
我们有一个包含几个 C# 项目和一个安装项目的解决方案。整个解决方案绑定到 TFS 源代码管理（并且整个文件夹结构映射到源代码管理）。
所有项目都有相同的输出文件夹 - 父文件夹映射到源代码管理，但输出文件夹未添加到源代码管理。
设置项目设置为将输出文件夹中的特定程序集添加到 GAC（文件系统编辑器 -> 添加 -> 程序集 -> 浏览）。 Visual Studio 会自动将这些程序集添加到源代码管理中。由于这些程序集是我们的项目，我们不希望它们出现在源代码管理中，因为它们会在每次构建时重新生成。 我们不想
使用主输出，因为：
- 安装程序添加了很多依赖项
- 排除它们很容易，但是每次我们更改引用或其他内容时，安装项目都会刷新，找到新的依赖项或类似的东西
- 我们希望控制哪些文件将与我们的安装一起分发而不会干扰安装项目
有什么想法吗？
We have a solution with few C# projects and one setup project. The whole solution is bound to TFS source control (and whole folder structure is mapped to source control).
All projects have the same output folder - parent folder is mapped to source control but output folder is not added to source control.
Setup project is set to add specific assemblies from output folder to GAC (File System Editor -> Add -> Assembly -> Browse). Visual Studio automatically adds those assemblies to source control. And since those assemblies are our projects, we don't want them in source control because they are regenerated on each build.
We don't want to use Primary Output because:
- Setup adds a lot of dependencies
- Excluding them is easy, but each time we change references or something, setup project gets refreshed, finds new dependencies or something like that
- we want to be in control what files will be dsitributed with our setup without setup project interference
Any idea?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在我看来，到处都是不好的做法。
首先，您的公司拥有 TFS、Visual Studio 2010，但仍然使用 即将过时 Visual Studio部署项目。不管你喜欢与否，迟早你都会迁移到 WiX。
如果您或您的利益相关者仍然坚持使用 vdproj，为什么要引用 GAC 的您自己的程序集？主要输出远非完美，但它在您的开发机器上胜过 GAC。
GAC 在运行时，而不是设计时 ©
最后，即使出于某种原因您仍然想引用自己的二进制文件，也可以从源代码管理中保存的通用 lib 文件夹而不是 GAC 中进行操作。
Sounds to me like bad practices all over the place.
First, your company has TFS, Visual Studio 2010 and yet -- still using the soon-to-be-obsolete Visual Studio Deployment project. Like it or not, sooner or later you'll be migrating to WiX.
And if you or your stakeholders still insist on vdproj, why reference your own assemblies from GAC? Primary Output is far from being perfect but it beats GAC'ing on your development machine.
GAC on runtime, not design time ©
Finally, even if for some reason you still want to reference your own binaries, do it from a common lib folder kept in the source control instead of the GAC.