what is difference between microsoft.aspnetcore.signalr.client and microsoft.aspnetcore.signalr.client.core? - nuget-package

There are two nuget packages for SignalR client:
Microsoft.AspNetCore.SignalR.Client and Microsoft.AspNetCore.SignalR.Client.Core.
Both ASP.NET Core, but I can't find any information why they both exist.
Probably Client.Core has limited functionality, but this is just my guess.

Both ASP.NET Core, but I can't find any information why they both exist.
The Microsoft.AspNetCore.SignalR.Client package depends upon the Microsoft.AspNetCore.SignalR.Client.Core package.
And from doc of "ASP.NET Core SignalR .NET Client", we can find that:
The Microsoft.AspNetCore.SignalR.Client package is required for .NET clients to connect to SignalR hubs.
Besides, if you do a test with only installing the Microsoft.AspNetCore.SignalR.Client.Core package in your client app, you would find you can not call WithUrl method to configure the HubConnection to use HTTP-based transports to connect to the specified URL.
And it would cause the error, like below.
'HubConnectionBuilder' does not contain a definition for 'WithUrl' and no accessible extension method 'WithUrl' accepting a first argument of type 'HubConnectionBuilder' could be found (are you missing a using directive or an assembly reference?)

Related

Azure Function gives error: System.Drawing is not supported on this platform

(If this question is poorly worded, could someone please help me clear it up?)
I have an Azure Function (2.0) which relies on some System.Drawing code. I've added a NuGet reference to System.Drawing.Common (4.5.0).
After publishing the app, however, when the function is called, it produces the error:
System.Private.CoreLib: Exception while executing function:
[MyFunctionName]. System.Drawing.Common: System.Drawing is not
supported on this platform.
As far as I'm aware, System.Drawing.Common is supported on .NET Core now, which I believe is the environment in which my Azure Function is running. The actual project is a .NET Standard 2.0 project, though.
I am confused as to how to resolve this. I've tried converting the project to a .NET Core 2.1 project but that led to bizarre errors related to "Metadata generation failed" and an inability to find System.Runtime.
My project references Microsoft.Azure.WebJobs.Extensions.EventGrid (2.0.0-beta2) if that's relevant.
It's not about the CLR, it's about the sandbox.
System.Drawing relies heavily on GDI/GDI+ to do its thing. Because of the somewhat risky nature of those APIs (large attack surface) they are restricted in the App Service sandbox.
Win32k.sys (User32/GDI32) Restrictions
For the sake of radical attack surface area reduction, the sandbox prevents almost all of the Win32k.sys APIs from being called, which practically means that most of User32/GDI32 system calls are blocked. For most applications this is not an issue since most Azure Web Apps do not require access to Windows UI functionality (they are web applications after all).
Try to find an different library that doesn't rely on System.Drawing/GDI, like ImageSharp.
A little update can help a lot of people.
Now you can switch your Azure Function to v3:
in Function app settings panel -> Runtime version ~3
With this setup, your code run in a sandbox that support Core 3, (you don't need to rebuild your dll to Core3, i run my .net core 2.1 dll without errors), and surprise... you don't get this exception anymore:
System.Drawing.Common: System.Drawing is not supported on this platform.
Because the CLI can found GDI/GDI+ that need in the subsystem.
Now i can convert html to pdf without go crazy.

ELMAH for asp.net core

I am working on asp.net core webapp hosted on azure and I want to write my Elmah logs to my azure table storage .Many of the examples I looked into are using "API_KEY" and "logbucketId" but I am not sure what they are.
For instance as per elmah docs here https://docs.elmah.io/logging-to-elmah-io-from-aspnet-core/
app.UseElmahIo(
"API_KEY",
new Guid("LOG_ID"),
After installing nuget package, I don't see any API_KEY or LogBucketId in my appsettings.json file.
Where I can find my API_KEY and LogBucket_Id ?
https://github.com/ElmahCore/ElmahCore supports .net core now.
It is not based on Modules or Handlers, but Middleware.
It works fine although still limited.
The async calls are not being used at the moment. But it is quite extensible.
ELMAH doesn't work with ASP.NET Core, since ASP.NET Core doesn't work with HttpModules and HttpHandlers (ELMAH stands for Error Logging Modules And Handlers). ASP.NET Core does include a new (pre-release) diagnostic tool called ELM (Error Logging Middleware - creative, right?). You can find its source and samples here:
https://github.com/aspnet/Diagnostics/tree/release/1.1/src/Microsoft.AspNetCore.Diagnostics.Elm
Another option similar to ELMAH (and ELM) but with more capabilities is Glimpse:
http://getglimpse.com/
I realize neither of these directly answers your question but hopefully you'll find one or both of these alternative tools useful.
You can check ELMAH port to Net.Core version
https://github.com/ElmahCore/ElmahCore
Make sure it is matching your expectation before you use it.
Note: This new extension is in development and doesn't support all Elmah features.
ELMAH doesn't support ASP.NET Core. The documentation you are linking to is from elmah.io. While they have similar names and elmah.io uses ELMAH for some of its integrations, they don't share code or documentation.

Assembly not packaged for Azure worker role

I am facing a strange problem with packaging an assembly for Azure worker role. I am building a sample Azure cloud application having one website and a worker role. I am referencing a third party assembly, myasm.dll in both website and worker role project. The myasm.dll has dependency on two other assemblies. When I build the project all three(myasm.dll and two dependent assemblies) third party assemblies are getting copied to bin directory for both website and worker role projects. So far so good.
When packaging is done for worker role, off the three third party assemblies, only two assemblies are included in the package, the third assembly is not included. Strangely enough, packaging of Website project includes all three assemblies. I created one more worker role to test the behavior but same behavior was seen again.
Is this a known issue or something? Any help is highly appreciated.
I use VS2012 Update 4.
Package will not include any dll which is not explicitly used in your project or referenced. I know this problem occurs when you do not use type explicitly in a your project(old bug raised - with won't fix status)
I guess your best option is to explicitly reference those missing dll's (see here) or try to add dummy usage of types from missing dependencies.

Designing ServiceStack with RedisMQ

I am implementing a solution that has a web interface (service stack) and a long running job service (servicestack?).
I already implemented the web interface and found servicestack a really good framework for creating what i wanted. I used redis as a semi reliable object store.
Then i started to think about how to implement the job service.
What i originally thought i do was to set up a simple windows service and have the redis client pick up thinks marked for the job service ( how exactly i wasn't sure ). These are very long running jobs that require alot of resources so i want to throttle how many of them are running at a time and also if i could fan out with worker machines that would be nice.
Then i saw that ServiceStack has a RedisMQ that might fit the bill, and hence the question.
Should i create a seperate servicestack service and host it in a windows service. Then have a MQ interface on it and let the webservice post to that message queue jobs that need to run. Then the jobservice is decoulpled from the webservice and all is well.
or
Am i over thinking it and should just use the logic part of the service i already have running and implement the job logic there, could pop in a MQ but in the same process that would probably just be a waste of time. I could skip the message part entirely and just call the logic part straight with some throttling algorithm.
Also when i was testing this out i had trouble with creating the RedisMQ server
using ServiceStack.redis;
using ServiceStack.messaging;
var mqHost = new RedisMqServer(redisFactory, retryCount:2);
Returns RedisMQServer not found.
I did a full nuget install of the servicestack and servicestack.redis packages
install-package servicestack
install-package servicestack.redis
When i use object browser on the .dll i don't find any mention of the ReidsMQServer, the version i 4.0.15
I found this url https://github.com/ServiceStack/ServiceStack/blob/master/src/ServiceStack.Server/Messaging/Redis/RedisMqServer.cs
And would think that this should belong to the servicestack.redis reference.
Any help appreciated,
cheers
Redis MQ is in the ServiceStack.Server NuGet package, i.e:
PM> Install-Package ServiceStack.Server
When in doubt as to which package to install, refer to ServiceStack's download page, e.g: https://servicestack.net/download#mq

Servicestack - run built-in clients on the .net client profile framework

Is it possible to run servicestack's built-in clients on the .net client profile framework?
When i change the target framework property in the project settings to ".Net Framework Client Profile" and try to compile i get the following message: the namespace ServiceClient does not exist in the namespace servicestack.
We use servicestack services to send exception reports. We use the JsonServiceClient and feel really comfortable with it. We could change the target framework - but then we have to check all installations for the availability of the full .net framework.
Any idea how to solve this?
Thanks.
From the package contents of the latest ServiceStack.Common package there seems to be no -client version included (See Common Framework and Profile Targeting Examples under NuGet - Creating and Publishing a Package).
You should either change the target framework the full profile or pull the code from ServiceStack's GitHub Repo and try to build it for client profile yourself. The downside of this is that you will loose Nuget's awesome update features...
You could off course file an issue at GitHub for the guys maintaining ServiceStack to add a client profile version of the framework, but I guess that there's a good reason for why it's not there already.

Resources