gRPC and ASP.NET Core: serverside reflection - asp.net-core

I've been trying to implement the concepts of serverside reflection described in https://github.com/grpc/grpc/blob/master/doc/server-reflection.md and for C# https://github.com/grpc/grpc/blob/master/doc/csharp/server_reflection.md in the implementation of ASP.NET Core. You have to somehow configure Kestrel to enable Reflection first. I just don't succeed and have to give up. This is the tricky part that somehow has to be implemented in ASP.NET Core.
// the reflection service will be aware of "Greeter" and "ServerReflection" services.
var reflectionServiceImpl = new ReflectionServiceImpl(Greeter.Descriptor, ServerReflection.Descriptor);
server = new Server()
{
Services =
{
// the server will serve 2 services, the Greeter and the ServerReflection
ServerReflection.BindService(new GreeterImpl()),
ServerReflection.BindService(reflectionServiceImpl)
},
Ports = { { "localhost", 50051, ServerCredentials.Insecure } }
};
server.Start();
Does somebody know how to enable serverside reflection in ASP.NET Core with Kestrel? Or even better has a complete working example of serverside reflection in C# ASP.NET Core?
Update
It seems that the default implementation of .NET Core 3.1 doesn't support the reflection yet. The NuGet https://github.com/grpc/grpc-dotnet/ does work and seamlessly integrates in ASP.NET Core. The example covers discovering services on a server. I can't find concrete descriptions how to iterate through all methods on a service and all fields in a message. Maybe JamesNK can help?

Related

DependencyResolver in ASP.NET Core. Also how to access HTTPConfiguration in ASP.NET Core?

We are migrating our project from ASP.NET Web API to ASP.NET Core 6.0 Web API as part of that we having following below lines of code.
DependencyResolver.SetResolver(new AutofacDependencyResolver(container));
config.DependencyResolver = new AutofacWebApiDependencyResolver(container);
The config is a HTTPConfiguration but while migrating to .NET 6.0 I was not able to access HTTpConfiguration from WebApplicationBuilder or WebApplication.
Please let me know how to access HttpConfiguration in .NET 6.0 and assign the DependencyResolver.
In .NET Core you don't explicitly set the dependency resolver and there's no HttpConfiguration. It's a whole different application and hosting model. I'd recommend following some of the tutorials about ASP.NET Core - it's similar, but different enough that the answer to this question would basically be to replicate all the existing migration docs and tutorials already on the Microsoft doc site.

Blazor #inject data service depending on project

I have a shared .net 6 project for just controls. I wanted to use the same controls in .Net Blazor Web as with .Net Maui Blazor. I was trying to do this but it doesn't work. Any idea how I can switch what data service is called based on what's calling it?
#*#if(AppDomain.CurrentDomain.FriendlyName == "nu.web")
{
#inject IDataService _db
}
else
{
#inject IHttpService _db
}*#
Thanks for any help...
From Bennyboy1973’s hint… I removed the extra interface IHttpService and used IDataService on both HttpService and DataService.
Then on the .Net Blazor web app startup.cs file:
builder.Services.AddSingleton<IDataService, DataService>();
Then on the .Net Maui Blazor app MauiProgram.cs file:
builder.Services.AddSingleton<IDataService, HttpService>();
If anyone cares about why I wanted it this way… I get a slight performance improvement from calling SQL via Dapper on web and .Net Maui doesn’t allow it… So I’m calling the same Dapper SQL via Minimal API.
Thanks again for all the answers

How to use Service Fabric service with AspNet Core WebApi and Autofac and run TestServer

I can't figure out how to use an AspNet Core 3.1 Web Api with Service Fabric and Autofac, and also how to have it ready for a TestServer to run for integration/functional testing.
The documentation is very incomplete.
Autofac documentation shows how to modify Program.cs to build autofac container, but it does not mention anything about the Startup.cs class that all the web api have:
https://autofaccn.readthedocs.io/en/latest/integration/servicefabric.html
Also the only example that Autofac has for service fabric is not a web api: https://github.com/autofac/Examples/tree/master/src/ServiceFabricDemo
There are other questions without valid answers:
Service Fabric AspNet Core 3.1 Autofac WebHostBuilder
Does anybody have any example on how to achieve this?
I can achieve the following (please see my GitHub repository with the sample)
Service fabric with stateless AspNet Core WebApi project (dotnet core 3.1)
Using Microsoft Dependency Injection to register services
Using TestServer to run integration tests on the http endpoint, and able to overwrite dependency injection registrations in a clean way without having to create another Startup class
I want the exact same, but using Autofac as DI container.
UPDATE 1:
I can't add Autofac to a WebHostBuilder and the ConfigureServices(IServiceCollection services) must be void as per AspNet Core 3.1+, so this is where I'm stuck. How to replace MS Dependency Injection in my sample
Event after the bounty there is not an answer to this. Maybe it's not possible as service fabric requires WebHost and not generic host.
In any case, I managed to have it working with older versions. Here's my repository where I show a sample on how to run AspNetCore2.1 with DotNetCore2.1 (LTS) and Autofac under Service Fabric. I use the webhost builder, not the generic one.
https://gitlab.com/sunnyatticsoftware/training/sasw-aspnetcore-testing/-/tree/master/aspnetcore2_1_autofac_servicefabric
Still, it'd be nice to eventually have a valid answer to the question.
I have NO idea if this works for the TestServer. It does however work fine with during ordinary hosting.
The exact thing you are looking for would be this line: services.Replace(ServiceDescriptor.Singleton<IServiceProviderFactory<ContainerBuilder>>(new AutofacServiceProviderFactory(null)));
protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
{
return new[]
{
new ServiceInstanceListener(
serviceContext => new KestrelCommunicationListener(
serviceContext,
(url, listener) =>
{
return WebHost
.CreateDefaultBuilder()
.ConfigureServices(services =>
{
services.Replace(ServiceDescriptor.Singleton<IServiceProviderFactory<ContainerBuilder>>(new AutofacServiceProviderFactory(null)));
services.AddSingleton(serviceContext)
})
.UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.UseUniqueServiceUrl | ServiceFabricIntegrationOptions.UseReverseProxyIntegration)
.UseStartup<TStartupType>()
.Build();
}))
};
}
Hope it helps, it took me quite a while to arrive at this solution.

How to configure MessagePack on SignalR with Owin and WebApi 2?

We have a SignalR service that runs as a self-hosted OWIN app with Web API 2. It is configured like
resolver.Register(typeof(JsonSerializer), () => JsonSerializer.Create(serializerSettings));
app.MapSignalR(new HubConfiguration { EnableDetailedErrors = true, Resolver = resolver});
We want to replace our JsonSerializer with MessagePack. The obvious examples all configure it from a AspNet.Core web application context. I can't seem to find any examples with Owin self hosting.
EDIT: It looks like MessagePack is a new ASP.NET Core feature. We are running the older ASP.NET version and so I guess the real question is how to do binary formatting over ASP.NET SignalR.
It's not possible. I am migrating my solution to the AspNetCore version of SignalR.

ASP.NET Core middleware or OWIN middleware?

As I understand it, ASP.NET Core has support for OWIN middleware (via app.UseOwin()) in addition to its own native middleware.
What is the difference between ASP.NET Core middleware and OWIN middleware?
When designing a new middleware, how do I know if I should design it as a ASP.NET Core middleware or a OWIN middleware?
Your question made me curious and I would like to share, what I have learned so far.
Katana is the implementation of the OWIN spec. After version 3.0 of Katana this technology has been fully integration in the web stack we know as ASP.NET Core today.
While this transition much has stayed similar to the OWIN specifications. Although some changes have been made. In order to use existing OWIN middleware in ASP.NET Core the supports OWIN by an optional feature ("app.UseOwin()").
If you want to target with your middleware ASP.NET apps and ASP.NET core apps, then I would use OWIN middleware. If you want to give ASP.NET Core developers a first class citizen experience, then a ASP.NET Core middleware would be recognized as more "fitting".
Some information about the relationship between ASP.NET Core middleware and OWIN middleware can be found here:
Katana, ASP.NET 5, and bridging the gap
Katana Project
https://docs.asp.net/en/latest/fundamentals/owin.html
I have come to understand it as this; ASP.NET Core middleware is on a higher level than OWIN middleware which is on a lower level.
ASP.NET Core middleware has the advantage that it is much easier to develop a middleware in as you get passed in the HttpContext which you can use. The disadvantage is that the middleware you develop depends on ASP.NET Core.
OWIN is on a lower level and you get a OWIN environment which is a IDictionary<string, object>. The advantage is that is it not tied to ASP.NET hence can run on any OWIN server (such as Nowin). The disadvantage is that it takes more effort to code since you have to build your own context from the OWIN environment or use the OWIN environment dictionary directly and keep track of all OWIN keys and objects.
Edit: You don't have to keep track of OWIN keys yourself, you can use the OwinEnvironment class to get a strongly typed environment.
var environment = new OwinEnvironment(HttpContext);
var features = new OwinFeatureCollection(environment);