问题标签 [ihostedservice]

I know prior to Asp.Net 3.0 (or 3.1), to manually start a BackgroundService, we could derive it from IHostedService instead and change the DI registration to:

and then manually trigger the service start by injecting the service in the constructor, and calling StartAsync().

However, I can't seem to do that in Asp.Net Core 3.1. Having a look at the code for the StartAsync() method, background services are started before the app startup is completed.

What's the best way to manually trigger a background service to start?

Essentially, this is my setup:

Background Service

Consumer factory registration

Essentially this certService properties are only set when a request comes in and executes a middleware. And since when ExecuteAsync() in the background service tries to get an instance of consumer from the factory, is executed regardless, I dont have the IConsumer properly configured Thanks

在 WPF 应用程序中，我配置了一个托管服务以在后台执行特定活动（按照本文）。这是在 App.xaml.cs 中配置托管服务的方式。

并在启动时开始

现在我想在系统进入睡眠状态时停止托管服务，并在系统恢复时重新启动服务。我试过这个

停止主机工作正常但是当主机重新启动时，我得到' System.OperationCanceledException'。根据我的理解，托管服务的生命周期独立于应用程序的生命周期。我的理解错了吗？

这个问题- ASP.NET Core IHostedService 手动启动/停止/暂停（？）是相似的，但答案是根据配置暂停和重新启动服务，这似乎是一个黑客，所以我正在寻找一种标准方式。

有什么想法吗？

据我所知，可以添加多个托管服务以在同一个“主机”下运行，就像这个例子取自微软页面：

如果不是我创建三个不同的项目，则可以为每个项目注入三种不同的配置。

有没有办法在同一个项目中做到这一点？也许加载不同的配置文件（appsettings.json）？

喜欢：

• 对于托管服务GracePeriodManagerService appsettings.graceperiod.json
• 对于托管服务MyHostedServiceB appsettings.myHostedServiceB.json

或按文件夹分隔：

• 对于托管服务GracePeriodManagerService GracePeriodManagerService\appsettings.json
• 对于托管服务MyHostedServiceB MyHostedServiceB\appsettings.json

我需要创建一个进程（在 Kubernetes 集群中），每小时更新一个表中的寄存器。目前，在我的 kubernetes 中，我只部署了 net core api。

我的第一个选择是在一个与进程的上下文相关的 api 上创建一个 IHostedService（作为 SchedulerJob），但是我有一个问题：如果 api 在多个实例中部署，这可能是与数据并发相关的问题? 有人知道如何避免这种情况吗？也许这是个坏主意？

提前感谢

我如何属性注册一个包含IHostedService和自定义接口的类IMyInterface？

如在

class BackgroundTaskScheduler : BackgroundService, ITaskScheduler {...}

如果配置如下：

然后尝试将其注入客户端，如下所示：

生成一个错误，指出 ASP.net 无法解析BackgroundTaskScheduler，为什么？

在 Aspnet 核心中创建服务有不同的方法。IHostedService接口用于创建像Windows Service这样的服务。

在 WebApi 项目中使用IHostedService并将其部署为 Web 项目。一旦 API 项目启动，您的服务就会启动。

服务代码： 创建一个MyHostedService.cs类并将以下代码放入该类中。

班级

开始

停止

你的工作

启动.cs

我们在 .net 核心中有一个 API 项目，在 .net 核心中有一个库项目，我们在其中定义了后台进程（使用 IHosted 服务的后台服务）。

在 API 项目中，我们将后台服务的依赖注册为：

我们还有一些其他范围、瞬态和单例依赖项，例如：

在我们的后台服务项目中，在构造函数中，我们注入了一些作用域和瞬态依赖项（例如）：

我能够在 .net core 2.2 中解决这些作用域依赖项。我从我的 API 项目中获取所有这些值。当我从 API 项目调用我的后台服务时，正在调用后台进程构造函数。所以我得到了所有更新的依赖项。

当我将项目迁移到 .net core 3.1 时，问题就来了。现在我的依赖项为空。这些没有与我调用这些后台服务的 API 项目同步。我们正在使用.net core inbuild DI。IHostedService/Background 服务的构造函数在将应用程序部署到服务结构时被调用，它不会在从 API 调用后台进程时被调用。

我的 API 业务逻辑构造函数如下：

在这里，我正在注入、作用域和瞬态依赖项以及 2 个后台服务。每当我从“ serviceProvider.GetServices() ”中获取 IHostedService 的实例时，在 .net core 2.2 中，它都会调用在我的 DI 中注册的所有 IHosted 服务的构造函数，但在 .net core 3.1 中它不会调用背景的构造函数服务。

更新 -

我尝试将我的后台服务注册为Transient而不是AddHostedService，如下所示：

似乎它现在正在工作，每次我尝试解析类型时它都会调用构造函数：

像这样注册 IHostedService 是否可取？会不会有什么影响？

尝试从 Azure 队列实现消息的消费者/接收者。我正在使用工作人员服务/后台服务项目.Net core 3.1。

以下是 Program.cs

以下是工作人员 service.cs

然而，该方法的一个变体有效，但它抛出了一个错误“消息处理程序已被注册”。

当我在控制台项目中实现它时，它可以工作。不确定这里缺少什么。

抱歉标题含糊不清，很难解释。我有以下设置：

• 我正在运行托管在 Service Fabric 中的 .NET Core 2.2 Web API。
• 此 API 的部分职责是监视外部 FTP 存储中是否有新的传入文件。
• 每个文件都会触发一个 MediatorCommand来调用处理逻辑。
• 我已经实现了一个基于https://docs.microsoft.com/en-us/dotnet/architecture/microservices/multi-container-microservice-net-applications/background-tasks-with-ihostedservice和https://docs.microsoft.com/en-us/dotnet/architecture/microservices/multi-container-microservice-net-applications/background-tasks-with-ihostedservice 的混合解决方案：/ /blog.maartenballiauw.be/post/2017/08/01/building-a-scheduled-cache-updater-in-aspnet-core-2.html。本质上，这是在此 APIIHostedService中注册的实现。Startup.cs它基本上是一个在进程中运行的后台服务。

至于问题。上述解决方案在 1 节点集群上运行良好，但在 5 节点集群上运行时会导致处理“重复”。问题在于，在一个 5 节点集群上，当然有 5 个相同ScheduledTasks的运行，并且都将同时访问FTP上的同一个文件。

我已经意识到这在某种程度上是由于关注点分离不当造成的——也就是 API 不应该对此负责，而是应该由一个完全独立的进程来处理这个问题。

这让我想到了 Service Fabric 支持的不同服务（有状态、无状态、Actor 和 Hosted Guest Exe）。Actor似乎是唯一一个运行单线程的，即使在 5 节点集群上也是如此。此外， anActor似乎不太适合这种情况，因为它需要被触发。就我而言，我基本上需要一个按计划一直运行的守护进程。如果我没记错的话，其他有状态/无状态服务也将使用 5 个“克隆”运行，并且只会导致与我目前遇到的相同问题。

我想我的问题是：如何使用Service Fabric进行高效的后台处理并避免这些多线程/重复问题？提前感谢您的任何意见。

我正在开发 .Net CORE 3.1 Web API。我们使用 BackgroundHostedService 来处理耗时的操作。我们需要从该托管服务访问 HttpContext，如下所示：

accessor.HttpContext 在这里为空。

我试图找到一个很好的解决方法。其中之一是在 HttpContext 处理中捕获数据并将该数据传递给托管服务。Microsoft 文档中描述了该方法： Access HttpContext in ASP.NET Core (Section - HttpContext access from a background thread)

它工作正常。但是，当您向项目中添加许多不同的 nuget 包并且这些包访问 HttContext（并且所有这些都发生在 HostedService 中）时，进行此类修复会变得非常痛苦

**我的问题：** 有一些更好的修复/解决方法可以在 Http 请求中制作 HttpContext 的“快照”并将该“快照”传递给托管服务？