【问题标题】:Running an executable independently and simultaneously with "dotnet watch run"使用“dotnet watch run”独立并同时运行可执行文件
【发布时间】:2021-06-14 04:15:27
【问题描述】:

我有一个 ASP.NET Core 5 项目,它作为主要功能运行一个典型的 ASP.NET Web 项目。所以通常我用dotnet watch run 启动它,服务器在后台连续运行。但我也在尝试添加一种方法来执行控制台命令到同一个可执行文件,它重用服务器版本的代码,但不从 ASP.NET 启动实际的 WebHost。命令行版本应该能够与已经运行的服务器版本一起运行,或者完全独立运行。

现在的问题是,很明显我正在做一些 dotnet run 不适合的事情,因为构建非常不稳定并且经常失败并出现无益的错误(例如文件访问错误,.不支持在后台运行时再次运行 dotnet run,因此我正在尝试寻找不同的方法来执行此操作。

整个事情在 Docker 中运行,尽管这对于我的具体问题可能没有任何改变。我正在使用 VS Code,因此 Visual Studio 特定的解决方案对我不起作用,它必须单独使用 dotnet CLI 运行。

我想要做的是在开发过程中在后台有一个dotnet watch run,以及一种只执行它单独构建的二进制文件而不触发导致问题的同时构建的方法。至少据我所知,这应该避免我遇到的问题,如果我在这里错了并且同时运行 dotnet rundotnet watch run 不应该导致构建问题,请在这里纠正我。我假设运行单独的 dotnet build 会遇到相同的问题,并且我在 dotnet CLI 文档中看不到任何适合我的用例的内容。

当我的项目仍在后台通过dotnet watch run 运行时,如何安全地再次运行我的开发项目?

【问题讨论】:

  • 构建两个然后运行? dotnet builddotnet run --no-build

标签: c# .net-core dotnet-cli


【解决方案1】:

一种快速的解决方法是使用不同的构建配置(即dotnet watch run -c Debugdotnet run -c Release)。如果您没有覆盖默认输出目录 (./bin/<configuration>/<framework>/),您将有效地使用应用程序的两个编译版本,避免那些“不稳定的构建”。

您也可以为此目的使用create your own build configuration(即dotnet run -c My_Debug)并将其配置为具有“调试”属性,从而避免使用默认的Release 配置。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2022-01-18
    • 2011-06-21
    • 2015-10-13
    • 1970-01-01
    • 1970-01-01
    • 2012-08-22
    • 1970-01-01
    相关资源
    最近更新 更多