问题标签 [projects-and-solutions]

将解决方案拆分为逻辑层时，何时最好使用单独的项目而不是仅按文件夹分组？

是否可以在 Visual Studio 2008 中打开项目而不打开上次我打开项目时打开的所有文件。我习惯于在处理它们时保持许多文件打开，所以下次我打开项目时，它（非常缓慢地）将一堆文件加载到我什至可能不需要打开的编辑器中。我已经搜索了设置，找不到任何东西来阻止这种行为。

我已经看到在 Visual Studio 2008 中创建的解决方案无法在 Visual Studio 2005 中打开并尝试了解决方法 1。但尝试解决方法 2。

但是由于该链接有点陈旧并且出于绝望在这里询问：是否有可用的转换器？

我还没有 VS2008，我想打开一个在 vs2008 中完成的开源解决方案。

猜猜我必须摆弄或等到vs2008发货。

我经常使用 Visual Studio 的多个实例，经常在同一解决方案的不同分支上工作。

Visual C++ 6.0曾经在其标题栏中显示当前源文件的完整路径，但 Visual Studio 2005 似乎没有这样做。这使得计算出我当前正在查看的解决方案的哪个分支（我所知道的最快方法是将鼠标悬停在选项卡上，以便您将源文件的路径作为工具提示获取）比它应该稍微尴尬一些。

有没有办法将完整的解决方案或文件路径放入标题栏中，或者至少在某个始终可见的地方，这样我就可以快速判断哪个分支被加载到每个实例中？

很多次我看到 Visual Studio 解决方案有多个共享源文件的项目。这些公共源文件通常位于公共目录中，在解决方案资源管理器中，它们的图标会在左下方显示一个链接箭头。

但是，每当我尝试将源文件添加到该项目主目录之外的项目时，它只会自动将其复制到目录中，这样我就不再拥有共享副本。

我发现我可以通过在文本编辑器中手动打开项目文件并将路径修改为“../../../Common/Source.cs”之类的路径来解决这个问题，但这更像是一种黑客攻击想。

是否有设置或我可以更改的内容允许我在 IDE 中执行此操作？

在回答了这个问题之后，我认为收集一些使用 MSVS 解决方案和项目的提示和技巧会很好。

这是我的清单：

• 如何避免自动保存新项目以减少文件系统中的垃圾。

  取消选中工具->选项->项目和解决方案->创建时保存新项目

• 如何将公共文件添加到多个项目而不将其复制到项目目录。

  右键单击一个项目，选择添加->现有项目->添加为链接（按添加按钮上的小箭头）

• 如何将项目添加到解决方案而不将其包含在构建过​​程中

  右键单击解决方案，选择Add->New solution folder。
  右键单击创建的文件夹，选择添加->添加现有项目

• 如何从 Visual Studio 编辑项目文件？

  右键单击项目并选择Unload Project，右键单击已卸载的项目并选择Edit。或者安装Power Commands并选择Edit Project File

• 如何在项目树中对文件进行分组（如 WinForms 控件的自动生成文件）

  打开项目文件进行编辑。

你还有什么要补充的吗？

多年来，我创建并调整了一组 NAnt 脚本来执行完整的项目构建。主脚本采用单个应用程序端点（例如 Web 应用程序项目）并从源代码控制中对其进行完整的构建。这些脚本预先配置了有关构建输出位置、源代码控制地址等的必要信息。要点是您可以提供很少的信息并从头开始构建给定的项目。这满足了我问题的“任意”部分。

过去，我曾为生产一些软件产品（主要是 Web 应用程序）的公司工作。这种环境非常适合典型的持续集成设置，其中每个产品都有一个集成商。我已经设置了集成器来充当 CI 构建以及集成器来处理完整的发布候选构建和 QA 部署。这些集成器使用主构建脚本，因此集成器本身只不过是源代码控制监控和对主 NAnt 脚本的调用。

我现在为一个创建许多应用程序的开发组工作。通常，开发人员被要求支持最初由其他人构建的应用程序。当我开始时，没有构建管理。作为一个 4 人团队的首席开发人员，我在团队中处于一个特别独特的位置，负责一个业务部门的产品套件（大约六个完整的系统）。我已经使用主构建脚本实现了 CruiseControl.Net，用于执行 CI 构建和 RC 构建。这适用于企业产品套件中的固定项目集。

我已经使用 CCNet 很多年了，所以我完全知道它可以做什么。我非常尊重它对持续集成领域的贡献，因为我将它用于我的产品套件中的所有项目。我已经向我的团队强调，使用官方 RC 构建集成商作为主构建器，用于开发以外的任何位置。这为 CCNet 控制的固定项目集提供了很好的控制。

但是，还有其他开发人员构建其他应用程序。其中一些是 1 个开发人员项目，这些项目在进入项目生命周期之前通常甚至不在源代码控制中（我正在尝试更改其他内容）。其中许多项目都是一次性的，在部署后不会有太多的开发生命。尽管如此，他们仍然需要得到支持。支持这些的一个重要事实是，如果没有对这些项目进行集中构建管理，那么进入 QA 和最终生产的候选发布版本将在单独的开发人员机器上完成。当然，这提供了零保证，即在开发人员机器构建的其他因素中，一切都在源代码控制中。

我一直试图解决的问题是：我可以使用什么样的系统来提供对这些任意构建的集中控制？这绝对不是一个独特的问题。然而，在我所做的关于集中构建、构建自动化和持续集成的大部分阅读中，重点是固定的项目/产品以及支持对它们进行持续开发的任务。不断开发新项目的企业使用哪些类型的流程？他们不使用这些类型的流程吗？

虽然主构建脚本确实存在于构建服务器上，但它们使用起来很笨拙。此外，我更愿意限制对构建服务器的控制台访问。因此，需要一些管理系统来提供更轻松的访问权限，以便在中央系统上启动任意构建。

我意识到我正在寻找的东西可能隐藏在 MS Team Build 的掩护下。不幸的是，每当我开始阅读它时，当我开始进入 MS 营销材料并很快迷失方向时，我就会有一种流沙的感觉，从来没有真正发现我想做的事情是否可以用它来完成。此外，在过去有关 Team Foundation Server 和 Team System 主题的一些一般性讨论中，许可成本已被视为可能的阻碍因素。

我很想听听任何解决了这个问题的人的意见，他们可能会提供建议。我已经围绕我的主“构建任何项目”构建脚本在集中构建系统上做了一些工作。然而，我所拥有的还处于起步阶段，主要是为了支持我所从事的项目类型。目前缺乏处理许多应用程序类型或使用 Visual Studio 可能的大量项目/解决方案配置所需的支持。

是否有任何免费工具可用于查看解决方案用户选项文件（解决方案文件随附的 .suo 文件）的内容？

我知道它基本上被格式化为文件中的文件系统，但我希望能够查看内容，以便弄清楚我的解决方案和自定义的哪些方面导致它随着时间的推移变得非常大。

我们有一个场景需要我们解析大量电子邮件（纯文本），每个电子邮件“类型”都是针对不同平台运行的脚本的结果。有些是制表符分隔的，有些是空格分隔的，有些是我们还不知道的。

我们将来也需要支持更多的“格式”。

我们是否使用以下方法寻求解决方案：

• 正则表达式
• 简单的字符串搜索（使用 string.IndexOf 等）
• 莱克斯/雅克
• 其他

整体解决方案将在 C# 2.0（希望是 3.5）中开发

类人猿同胞、睡莲和桨轮！

我正在使用 VS 2008 在 C#/.NET/WPF 中开发一个 Windows 桌面应用程序。该应用程序需要在 Vista 和 XP 机器上安装和运行。我正在使用安装程序/Windows 安装程序项目来安装该应用程序。

我的应用程序需要对 SQLCE 数据库文件 (.sdf) 和与我正在使用的第三方控件相关的一些其他数据库类型文件的读/修改/写访问权限。这些文件应在 PC 上的所有用户/登录名之间共享，其中任何一个都不需要成为管理员。当然，这意味着文件不能放在程序自己的安装目录中（就像在 Vista 到来之前经常发生的那样，是的，是的！）。

我原以为解决方案很简单。Vista 和 XP 都有用于此目的的共享应用程序数据文件夹。（Vista 中的“\ProgramData”，XP 中的“\Documents and Settings\All Users\Application Data”。） .NET Environment.GetFolderPath(SpecialFolder.CommonApplicationData) 调用可用于在给定 PC 上查找这些文件夹的路径，是的， 是的！

但我不知道如何将 shared-application-data 文件夹指定为安装项目中的目标。

Setup 项目提供了一个“Common Files”文件夹，但该文件夹用于共享程序组件（不是数据文件），通常位于“\Program Files”下，并且具有与“\Program files”中其他任何内容相同的安全限制，是的是的！

安装项目提供了一个“用户的应用程序数据”文件夹，但这是一个每个用户的文件夹，这正是我想要避免的，是的，是的！

是否可以从 VS 2008 安装项目以强大的跨 Windows 版本的方式将文件添加到 shared-app-data 文件夹？谁能告诉我怎么做？