Base solution for your next web application
Ends in:
01 DAYS
01 HRS
01 MIN
01 SEC

Activities of "aaron"

Detailed documentation with an example on how to begin a unit of work explicitly with IUnitOfWorkManager: https://aspnetboilerplate.com/Pages/Documents/Unit-Of-Work#iunitofworkmanager

It is not reasonable, if even possible, to expect ABP or ASP<span></span>.NET Zero to create a DB connection for every class that you inject.

This is not about "wired up".

Instances have to be created and injected into the requesting service before ABP can begin a unit of work for you.

GetAllIncluding is "safe" and returns a query, but you are evaluating that query outside a unit of work yourself.

In general, it is bad to make DB calls in constructors.

I'm not sure if the problem lies with A0, ABP, Windsor, or some combination of the 3.

Or, in this case, your usage.

There is no unit of work in the constructor.

Not recommended, but you could try to inject IUnitOfWorkManager and begin a unit of work explicitly in the constructor.

Did you register the service by successfully calling services.AddAzureQueueLibrary in Startup.ConfigureServices?

But AddAzureQueueLibrary is not part of IServiceCollection even after the class library has been added as a dependency.

You need to add the appropriate using directive based on the namespace of the extension method:

using AzureQueueLibrary.Infrastructure;

I believe AllowAnonymousSignalRConnection only affects requests from clients.

By the way, can the issue be reproduced on your local machine?

Word from SignalR authors

aspnet/AspNetCore#6701 ("Writing is not allowed after writer was completed", with SignalR 1.1) appears to be fixed and shipped with ASP<span></span>.NET Core 3.0 and will not be backported as per dotnet/aspnetcore#10043 (comment 491485101):

Do we need to backport this?

Worst case it's an erroneous error log. There is no functional issue here. Based on that I don't think we should, but open to other opinions.

Possible workaround

Disclaimer: I have not tried this. Of course, the actual fix is to upgrade to ASP<span></span>.NET Core 3.0 but I suppose that may be impractical for some.

Since the issue appears to be with SignalR 1.1, you can try downgrading Abp.AspNetCore.SignalR to 4.0.0, which depends on SignalR 1.0.4.

Since ABP 4.4+ handles multiple notification notifiers rather than injecting a single implementation, you likely need the following in your module's Initialize method:

Configuration.Notifications.Notifiers.Add<SignalRRealTimeNotifier>();

Duplicate of aspnetboilerplate/aspnetboilerplate#5230

The fix will be released in ABP v5.2.

Meanwhile, you can subclass SignalRRealTimeNotifier and replace it in Configuration.Notifications.Notifiers.

Show your Publish call.

Possible duplicate of aspnetboilerplate/aspnetboilerplate#5138, which has a fix that will be released in ABP v5.2.

Meanwhile, you can resolve this by subclassing WebClientInfoProvider with the fix from aspnetboilerplate/aspnetboilerplate#5139 and replace service IClientInfoProvider.

Showing 51 to 60 of 1543 entries