0

这是背景，我们有一个解决方案文件（a.sln），其中包含 2 个项目（service.csproj 和 client.csproj）。还有另一个旧的解决方案文件 (b.sln)，其中包含 3 个项目（service.csproj、client.csproj 和 test.csproj）。我们也不使用此解决方案文件和测试项目。

我们使用 NANT 脚本进行编译。在 NANT 中，我们使用<exec> task调用“devenv.com”来编译解决方案文件。我试图对构建脚本进行一些更改（在构建过程中动态生成服务的代理），因此我试图单独编译 service.csproj 文件。我更新了 NANT 脚本，如下所示：

<exec program="${visualstudio.install.dir}\devenv.com" commandline="&quot;${base.dir}\Service.csproj&quot; /rebuild ${config}" failonerror="true" />

但是当执行上述行时，它会编译（按以下顺序）

一个。client.csproj b. 服务.csproj c. 测试.csproj

service.csproj 没有对客户端和测试项目的任何项目引用。

我想知道到底发生了什么以及客户端/测试项目是如何编译的。

这是我发现的，我们有以下文件夹结构：

MyFolder -> 

    -> Service
        service.csproj
        b.sln
    -> Client
        client.csproj
    -> Test
        test.csproj
    a.sln

由于 b.sln 已过时且未使用，它位于 MyFolder -> Service 文件夹（与 service.csproj 文件相同的文件夹）。（在我的新公司中，开发人员对此非常不满，以至于他们不会删除未使用的文件，而是继续将其重命名为 _old。）

devnenv.com 以某种方式从 b.sln 文件中获取项目文件并编译它们。我删除了 b.sln 文件，脚本编译 service.csproj 没有任何问题。但是当 service.csproj 和 b.sln 在同一个文件夹中时，visual studio (devenv.com) 尝试编译其中提到的所有 3 个项目解决方案文件。

有人对正在发生的事情有任何想法吗？

4

1 回答 1

1

这是我从微软那里得到的答案：

当您直接打开项目文件时，Visual Studio 会应用一些启发式方法来尝试定位父解决方案文件。如果 Visual Studio 在项目目录或父目录中找到具有匹配项目名称的解决方案文件，则 Visual Studio 将使用该解决方案。由于 devenv /build 试图直接从 UI 重现构建行为，所有这些启发式方法仍然适用。由于已失效的 b.sln 包含 service.csproj，它被启发式方法拾取，在某些情况下，这可能会导致解决方案中的其他项目也被构建。

您可以通过两种方式解决此问题。要么从项目的文件夹树中删除失效的解决方案，要么直接执行 MSBuild 以构建 services.csproj。如果您将 .*proj 文件传递​​给 MSBuild，它不会应用任何解决方案启发式方法。

于 2013-09-16T21:42:43.153 回答