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

Activities of "rickfrankel"

Hey @devinedon,

Undo those changes in the SignalR helper.

What happens is the client code makes a call to https://youapisite/signalr/negotiate?enc_auth_token=bigtokenhere&negotiateVersion=1

This is an API in the the host site that then returns a payload which contains the URL to use. In my case something like this.

{ accessToken: xxxx, availableTransports: [], negotiateVersion: 0, url: "https://myazure.signalr.net/client/etcetcetc }

I assume if you use the network tab in the browser debug tools you are seeing this API return localhost for you.

https://docs.microsoft.com/en-us/azure/azure-signalr/signalr-concept-internals

This negotiate endpoint is exposed by registering the AzureSignalR correctly on the server.

From the looks of your startup.cs it looks to be the same as mine (I'm on V10 so some small differences but have been using Azure SignalR since v7).

I would be confirming that the API project that your front end code is calling is the same host backend that you have your configured startup.cs in. Eg: Somehow you don't have two API hosts running in the backend.

Also confirm in the appsettings.json in your host project that you have "AllowAnonymousSignalRConnection": "true"

Not sure that will make a difference but it does affect the security of the call to the /signalr endpoint.

Hope that gets you in the right direction.

It really does look like something is not registering on the server correctly and thus the negotiate call is not returning the right data.

Can you provide more of the host project startup.cs file.

Assuming you are using the Angular front end. What do you have in your package.json for signalr.

I am using "@microsoft/signalr": "^5.0.1",

Everything just works for me.

Also @ismcagdas is talking about the config files in the angular folder not on the server. They shouldn't matter too much however if you can login correctly.

Hi BitMan,

The issue here is what SignalR backplane are you using? When there are multiple webservers they all need to share a SignalR backplan to be able to communicate correctly with each other.

The way I solved this was switching to an Azure SignalR service which takes care of all the signalr infrastructure for you.

Simply setup an Azure SignalR service and then update the following in your startup.cs of the web.host project.

        services
            .AddSignalR(options => { options.EnableDetailedErrors = true; })
            .AddAzureSignalR(options => options.Endpoints = new ServiceEndpoint[]
            {
                new ServiceEndpoint(_appConfiguration["SignalR:PrimaryConnectionString"], EndpointType.Primary, "Name1"),
                new ServiceEndpoint(_appConfiguration["SignalR:SecondaryConnectionString"], EndpointType.Secondary, "Name2"),
            });

You will have to setup configuration in your appsettings.json.

If you don't want to do that then you'll need to try and put in the Redis or DB based backplanes but websocks still would likely want ARR type connections which is why MS recommend moving away from trying to run SignalR infrastructure yourself.

Cheers

Hi Marble,

I've worked around this by changing the TimeZoneService.cs

    public List<NameValueDto> GetWindowsTimezones()
    {
        return TZConvert.KnownWindowsTimeZoneIds
            .Where(tz =>TZConvert.TryGetTimeZoneInfo(tz, out var notUsed))
            .OrderBy(tz => TZConvert.GetTimeZoneInfo(tz).BaseUtcOffset)
            .Select(tz => new NameValueDto
            {
                Value = tz,
                Name = TZNames.GetDisplayNameForTimeZone(tz, "en-US")
            }).ToList();
    }
    
    I used a nuget package https://github.com/mj1856/TimeZoneNames to make this work.
    
    It works acceptably for me.  It's not perfect however.

So this was really important to me as a lot of my customers are still on IE 11.

Here's the situation for me who's still on 8.7 and didn't go up to 9.

Version 8.7 (may have been earlier).
Introduced "@swimlane/ngx-charts": "^13.0.2",

This package depends on d3-array which doesn't support IE11 at all due to this issue (You can see it on src/count.js) https://stackoverflow.com/questions/55814151/why-does-this-function-expect-a-semicolon-only-on-ie11

Anyway this is known by the ngx-charts crew here. https://github.com/swimlane/ngx-charts/issues/1353

And the workaround is to go back to version 12 of ngx-charts which doesn't have the dependency on d3-array

I changed my package.json to "@swimlane/ngx-charts": "^12.1.0",

Deleted the yarn.lock and deletd all node_modules (probably not required but let's be safe here).

And I'm back in business with the site working acceptably enough in IE 11.

Not sure how stable this is but it seems to work.

Hey @omkarchoudhari and @demirmusa

No this is a big problem that will need to be solved.

The workaround is to d change your package.json from @angular-devkit/build-angular": "~0.901.0", to "@angular-devkit/build-angular": "0.901.6",

For me the ~ caused an upgrade to 0.901.9 which has dependencies way down the list which ultimately upgraded globby.

The upgrade to globby ultimately then changes the behaviour of this line in the gulpfile.js and change the way the styleEntries array looks, which causes the error you see above.

    styleEntries[styleBundle.output] = globby.sync(processInputDefinition(styleBundle.input), { noext: true });

So long story short to fix this for now. Delete your yarn.lock change the package.json to FIX the version to 0.901.6 and then run yarn again to install (I had deleted ALL node_modules as well).

And I'm back up and running.

Hi,

I have the ASP.Net Core & Angular package. I'm running 8.7 (just saw 8.8 released. Upgrade for another day).

I just noticed that on the Web.Public site the Error handler doesn't appear to exist.

Eg: If I go to our site with a made up page to generate a 404 you get this.

ERROR 2020-05-25 10:36:47,018 [20 ] AspNetCore.Server.IIS.Core.IISHttpServer - Connection ID "18374686481282236522", Request ID "8000006b-0000-ff00-b63f-84710c7967bb": An unhandled exception was thrown by the application. System.InvalidOperationException: The view 'Error404' was not found. The following locations were searched: /Views/Error/Error404.cshtml /Views/Shared/Error404.cshtml

This is in the startup.cs

        if (env.IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
        }
        else
        {
            app.UseStatusCodePagesWithRedirects("~/Error?statusCode={0}");
            app.UseExceptionHandler("/Error");
        }

However I don't see any Controller or Views for /Error?

Thanks Rick

Thanks @maliming I'll try look at implementing that Exception filter to filter it out of my logs as it's just filling it up with noise at the moment.

We do lots of switching to linked accounts in my setup.

@maliming I'll also test out you config option. we have noted this a lot in our production environment but you are right it hasn't caused any actual issue other than filling our logs.

cheers

Showing 101 to 110 of 128 entries