Question

我正在解决与IIS 502.5错误相关的步骤，但没有成功。

在绝望中，我尝试从命令行开始使用dotnet发布并得到一个构建错误，告诉我应用程序中有2个入口点，我需要＆＃34;使用/ main编译以指定包含的类型切入点。＆＃34;首先，我检查了我的解决方案，以验证项目中只有1个Main（）方法。即使在csproj文件中指定了目标命名空间，我也不遗余力地尝试使用/ main开关运行dotnet build，只是被告知/ main是一个未知的开关。

那么......错误信息是什么告诉我的，我在哪里可以看到我发现的确是一个令人尴尬的开发人员错误。

Answer 1

在绝望中我回过头来自我上次能够成功运行应用程序后提交的提交，我注意到我已将测试SDK库从15.3.0升级到15.5.0。由于我已经阅读了有关MSTest将一个程序main注入测试项目的几个问题，所以我回到了版本15.3.0，我的程序现在再次开发得很好。我不确定两个版本之间发生了什么变化，因为this blog post中的Andrew Lock在版本15.3.0中详细描述了这个问题。我不知道为什么我对版本15.3.0没问题。

还没有解决IIS中的502.5错误

的问题

Answer 2

正如您已经发现的那样，测试SDK会自动生成一个额外的代码文件，以确保测试“”库“中有一个main方法（然后它成为一个应用程序） - 这纯粹是为了使用构建逻辑只触发应用程序创建“可运行”输出，即使从未调用main方法，并且测试运行程序仅使用创建应用程序的副作用。

编译器生成有关/main参数的错误。直接调用csc.exe编译器时，如果有多个选项，这是在指定要使用的主要方法时使用的参数。

但是，用于构建项目文件（.csproj）的构建工具使用msbuild逻辑，然后调用编译器。这个msbuild工具只能理解msbuild特定的参数而不是csc的参数。不幸的是，错误消息是在假设csc命令行主机用于执行编译的情况下编写的。

MSBuild使用StartupObject属性将此配置选项传递给编译器。因此，可以在csproj文件中指定它（假设采用静态MyLib.AlternativeProgram.Main()方法）：

<PropertyGroup>
  <StartupObject>MyLib.AlternativeProgram</StartupObject>
</PropertyGroup>

或将其指定为了解用于设置属性的msbuild语法的命令的参数：

$ dotnet build /p:StartupObject=MyLib.AlternativeProgram

> msbuild.exe /p:StartupObject=MyLib.AlternativeProgram

错误＆＃34;与/ main编译以指定包含入口点的类型。＆＃34;意思

2 个答案: