从命令行运行时，启动UpObject与修改CSPROJ文件时具有不同的行为

Question

我只是偶然发现了MSBUILD的startupobject参数，该参数允许明确规范项目入口点。基于这个问题看来有两种方法可以指定此参数：

• 在给定项目的CSPROJ文件，
• 使用dotnet cli指定为MSBUILD属性。

我对第二个选项感兴趣，因此我用两个文件制作了一个简单的控制台应用程序，first.cs and second.cs：

first.cs 代码>

using System;

internal class First
{
    static void Main(string[] args)
    {
        Console.WriteLine("First");
    }
}

第二个

using System;

internal class Second
{
    static void Main(string[] args)
    {
        Console.WriteLine("Second");
    }
}

我发现的是，通过dotnet CLI指定startupobject CLI将调用正确的启动对象唯一如果从干净的板岩运行：

PS> dotnet run --project=test_multiple_entry -p:StartupObject=First
First
PS> dotnet run --project=test_multiple_entry -p:StartupObject=Second
First
PS> dotnet clean test_multiple_entry
...
PS> dotnet run --project=test_multiple_entry -p:StartupObject=Second
Second

另一方面，如果我实际上修改了CSPROJ文件的入口点，则无需dotnet Clean，它将自动找到正确的入口点。

我很好奇这种行为是否是故意的？为什么dotnet运行除非dotnet Clean在之前不使用正确的入口点？为什么修改CSPROJ文件直接工作？

Answer 1

startupobject是构建属性，而不是运行时属性。当dotnet运行时，会看到需要构建（例如源文件（包括csproj），比构建输出更新，或者没有构建输出（dotnet clean之后））然后它首先级联到dotnet build，然后将所有-P参数传递给构建。