I'm trying to use OWIN, SignalR and Autofac in a single project.
I'm setting things up with regards to signalR as follows:
// Create the AutoFac container builder:
var builder = new ContainerBuilder();
// ...[Register various other things in here]...
// register signalR Hubs
builder.RegisterHubs(Assembly.GetExecutingAssembly());
// Build the container:
var container = builder.Build();
// Configure SignalR with the dependency resolver.
app.MapSignalR(new HubConfiguration
{
Resolver = new AutofacDependencyResolver(container)
});
My issue is that when I use the Autofac SignalR integration, I can no longer get a signalR Hub Context on the server (in a webapi controller for example) and so can't send messages from server side to the connected clients. Something like the following is how I do this when I'm not using the Autofac signalR integration:
var hubContext = GlobalHost.ConnectionManager.GetHubContext<MyHub>();
hubContext.Clients.All.notification("Test Message");
But this doesn't work when I add Autofac into the mix - I don't get any error message and I do seem to get a hubContext, but calls on it don't actually seem to get to the clients.
If I comment out the use of the dependency resolver for signalR in the call to MapSignalR, the call to GetHubContext works again and messages reach the signalR clients sucessfully, but of course I can no longer use IoC on my hubs. e.g.
// Configure SignalR with the dependency resolver.
app.MapSignalR(new HubConfiguration
{
// Resolver = new AutofacDependencyResolver(container)
});
Can anybody tell me why using the AutofacDependencyResolver stops GlobalHost.ConnectionManager.GetHubContext from working correctly??
NOTE: One other thing I have tried is instead of using GlobalHost.ConnectionManager.GetHubContext() I tried injecting an IConnectionManager into the webapi controller from which I want to send a message to clients, then calling GetHubContext on that, but Autofac couldn't resolve the IConnectionManager.
I did find the following article by Piotr Szmyd which apparently allows this:
http://www.szmyd.com.pl/blog/wiring-signalr-with-autofac
but this appears to be based on obsolete signalR builds, and while there seems to be a nuget package for it here:
http://www.nuget.org/packages/SignalR.AutoFac/
it also seems well out of date.
If you use a custom dependency resolver with SignalR, you can no longer use GlobalHost unless you modify it:
GlobalHost.DependencyResolver = new AutofacDependencyResolver(container);
IHubContext hubContext = GlobalHost.ConnectionManager.GetHubContext<MyHub>();
// A custom HubConfiguration is now unnecessary, since MapSignalR will
// use the resolver from GlobalHost by default.
app.MapSignalR();
If you don't want to modify GlobalHost, you will have to manually resolve your IConnectionManager:
IDependencyResolver resolver = new AutofacDependencyResolver(container);
IHubContext hubContext = resolver.Resolve<IConnectionManager>().GetHubContext<MyHub>();
app.MapSignalR(new HubConfiguration
{
Resolver = resolver
});
For a complete answer, with SignalR, Autofac, and OWIN, I did the following:
// register IPersistantConnectionContext for access to SignalR connection
// and IDependencyResolver to enable inection of the container into its
// construction for the config object.
var builder = new ContainerBuilder();
builder.RegisterType<Autofac.Integration.SignalR.AutofacDependencyResolver>()
.As<IDependencyResolver>()
.SingleInstance();
builder.Register((context, p) =>
context.Resolve<IDependencyResolver>()
.Resolve<Microsoft.AspNet.SignalR.Infrastructure.IConnectionManager>()
.GetConnectionContext<SignalRConnection>());
// ... other registrations
var container = builder.Build();
var signalrConfiguration = new ConnectionConfiguration
{
Resolver = container.Resolve<IDependencyResolver>(),
};
app.UseAutofacMiddleware(container);
app.MapSignalR<SignalRConnection>("/signalr", signalrConfiguration);
// ... other middleware
In my controllers, I included a parameter of the type IPersistentConnectionContext and the correct instance is injected.
I was using a PersistentConnection, but it should be similar for Hubs.
To expand on Nathan's answer, I am using something similar with the key line being
builder.RegisterHubs(Assembly.GetExecutingAssembly()).SingleInstance();
in Startup.cs.
The line "SingleInstance()" ensures that only a single "instance" of the hub is used throughout the application.
Then I just use straightforward dependency injection into the constructor of the controller to get a pointer to the hub.
Related
I've got SignalR hubs in one .NetCore project and SignalR clients in another .NetCore project (to comply with internal infrastructure guidelines). I'm struggling with how to implement the client code that will provide the connection to the hubs. All my projects build fine, I'm just missing the connectivity part.
Client Project:
public class MyClientController
{
private readonly IHubContext<MyHub, IMyHubClient> _hub;
public MyClientController(IHubContext<MyHub, IMyHubClient> hub)
{
_hub = hub;
// THIS NEVER GETS CALLED/HIT BECAUSE I DON'T KNOW HOW TO REGISTER IT
_hub.Clients.All.BroadcastMessage("Notify", $"Hello everyone. This has been constructed");
}
}
I'm guessing I need to do some configuration in the Startup.Configure() method? I've installed the client package already,
EDIT: I added the following code, but it's complaining about the format (remember, this is not a relative path, it's in another service).
app.UseEndpoints(endpoints =>
{
endpoints.MapHub<MyHub>("http://localhost:60913/myHub");
}
Am I on the right path here?
The connection is made by mapping a route to your hub class. The docs have a good example. This includes:
// Add to services collection
services.AddSignalR();
// Map the route "/chathub" to a ChatHub class
app.UseRouting();
app.UseEndpoints(endpoints =>
{
endpoints.MapHub<ChatHub>("/chathub");
});
By the way, a hub can be a standalone class not associated to a controller.
So, I've registered a named client with the services collection in my Startup.cs:
services.AddHttpClient(someServiceName,
client => client.BaseAddress = baseAddress);
and now can inject an IHttpClientFactory from my service provider.
Using this IHttpClientFactory, I conjure up a client instance:
var client = httpClientFactory.CreateClient(someServiceName)
Once upon a time, it was necessary to be very careful about the disposing of HttpClient instances, as it was rarely the right thing to do.
However, now we have HttpClientFactory, does this matter any more? Should/Can this client be disposed without worry? e.g.
using (var httpClient = httpClientFactory.CreateClient(someServiceName))
using (var response = await httpClient.PostAsync(somePath, someData))
{
var content = await response.Content.ReadAsAsync<SomeResponse>();
//...
}
Calling the Dispose method is not required but you can still call it if you need for some reasons.
Proof: HttpClient and lifetime management
Disposal of the client isn't required. Disposal cancels outgoing requests and guarantees the given HttpClient instance can't be used after calling Dispose. IHttpClientFactory tracks and disposes resources used by HttpClient instances. The HttpClient instances can generally be treated as .NET objects not requiring disposal.
Check the source of DefaultHttpClientFactory:
public HttpClient CreateClient(string name)
{
if (name == null)
{
throw new ArgumentNullException(nameof(name));
}
var handler = CreateHandler(name);
var client = new HttpClient(handler, disposeHandler: false);
var options = _optionsMonitor.Get(name);
for (var i = 0; i < options.HttpClientActions.Count; i++)
{
options.HttpClientActions[i](client);
}
return client;
}
The instance of HttpMessageHandler stores unmanaged resources of the HttpClient. In the classical scenario the HttpClient creates the instance of HttpMessageHandler and disposes it while itself disposing.
You can see in the above code that different instances of HttpClient shares single instance of HttpMessageHandler and doesn't dispose it (disposeHandler: false).
So, the call of the HttpClient.Dispose does nothing. But it's not dangerous.
No. You should not dispose of your client. To be more general, you should not dispose of anything retrieved via a DI container, which in ASP.NET Core is by default the service collection. The lifetime is managed by the DI container, so if you dispose of the client, but it's later injected into something, you'll get an ObjectDisposedException. Let the container handle disposal.
This is actually a common confusion with IDisposable classes. You should personally only implement IDisposable if your class itself owns dependencies. If all its dependencies are injected, you should not implement IDisposable, since it doesn't own anything that needs disposal. Likewise, you should not dispose of anything injected into your class, as it doesn't own those dependencies. Only dispose of things you specifically new up. If you don't see the keyword new, you probably shouldn't be disposing.
I have an asp.net web api controller that sends a nservicebus message i.e. Bus.Send(). this api controller is owin self hosted using owinselfhost packages.
what is the correct way of injecting the bus if im using owinselfhost?
--edit--
here's the code.. im using autofac now.. having these still gives me a null ref exception on the bus...
references:
http://docs.autofac.org/en/latest/integration/webapi.html#owin-integration
http://docs.particular.net/nservicebus/containers/
--edit--
public void Configuration(IAppBuilder app)
{
var builder = new ContainerBuilder();
//this two controllers are from two separate class libraries.
builder.RegisterApiControllers(typeof(Test1Controller).Assembly);
builder.RegisterApiControllers(typeof(Test2Controller).Assembly);
var config = new HttpConfiguration();
config.MapHttpAttributeRoutes();
var container = builder.Build();
config.DependencyResolver = new AutofacWebApiDependencyResolver(container);
Configure.With()
.UsingContainer<AutofacObjectBuilder>()
.UnicastBus()
.SendOnly();
app.UseAutofacMiddleware(container);
app.UseAutofacWebApi(config);
app.UseWebApi(config);
}
You asked NServiceBus to use Autofac but you do not give it your container. If you pass your container there, you will get the bus injected to your controllers.
Configure.With()
.UsingContainer<AutofacObjectBuilder>(container)
.UnicastBus()
.SendOnly();
I try to separate one of my API projects into three different layers.
The API
Data access(repos + uow)
Data Entities
The API is using Asp.net Identity 2.0 with code from a sample I installed, just enough to work with OAuth Authorization.
However, When I do this separation, sometimes I get an error telling me that I need to reference the third layer(entities) from my first layer. And I can't figure out why. That would break the whole purpose of the separation, right?
For example, when I try to replace this line(from the API layer in Startup.Auth.cs, ConfigureAuth method)
app.CreatePerOwinContext(ApplicationDbContext.Create);
With
app.CreatePerOwinContext(uow.CreateDbContext())
A method that returns a new instance of the ApplicationDbContext.
I would expect that context to be returned from my second layer, where my UnitOfWork is(which in turn gets the ApplicationDbContext from the data layer).
Could someone please explain how this works?
To solve your issue you need to start use Interfaces and any DI-framework. Here I can provide you with the code if you want to start using AutoFac (https://code.google.com/p/autofac/wiki/WebApiIntegration).
When you installed AutoFac to your solution through Nuget. Add this part of code in your Global.asax.cs file.
protected void Application_Start()
{
...
SetupAutoFac();
...
}
private static void SetupAutoFac()
{
var builder = new ContainerBuilder();
builder.RegisterApiControllers(Assembly.GetExecutingAssembly());
var container = builder.Setup();
var resolver = new AutofacWebApiDependencyResolver(container);
GlobalConfiguration.Configuration.DependencyResolver = resolver;
}
Create this part of code in your BLL-layer:
public static class AutoFacConfiguration
{
public static IContainer Setup(this ContainerBuilder builder)
{
REGISTER ALL YOUR SERVICES AND UOW HERE
return builder.Build();
}
}
After this you can inject every services Interface to your ApiControllers, and the the WebAPi will only have a reference to your BLL-layer or to the layer where you put all your interfaces.
How can I use an existing IoC with SignalR 2.0?
From the tutorial, it seems I need to setup a class to be called from OWIN via an attribute:
using Microsoft.Owin;
using Owin;
[assembly: OwinStartup(typeof(SignalRChat.Startup))]
namespace SignalRChat
{
public class Startup
{
public void Configuration(IAppBuilder app /*HOW AM I GONNA GET UNITY CONTAINER HERE?*/)
{
var hubConfig = new HubConfiguration()
{
EnableJSONP = true,
EnableDetailedErrors = true,
EnableJavaScriptProxies = true,
Resolver = new SignalRUnityDependencyResolver(container)
};
// Any connection or hub wire up and configuration should go here
app.MapSignalR(hubConfig);
}
}
}
The problem here is that I already have a container, that's boot strapped and there are singleton instances in the container that needs to be shared with the MVC app shared under the same host.
However the trouble here is that unlike before, it doesn't look like I can call the MapSignalR method from my own code. Rather I need to rely on OWIN to do this for me. However OWIN is not aware of the container that I already setup.
What's the best way to resolve this? I have some very crude ideas how to hack a solution together using static variables to hold some of these - but I hate the very thought of it. The code will be brittle and order of operation could easily introduce a subtle bug.
Is there a way to get a hold of the IAppBuilder instance without having OWIN invoke the above method? This way I can control better when SignalR gets initialized and I can pass my own IoC into the configuration.
In my case I have created a custom hub activator which uses a shared container between my app and signalR (by constructor injection) that way you´ll have single composite root for the whole application.
try the following:
public class CustomHubActivator : IHubActivator
{
private readonly Container _container;
public MseHubActivator(Container container)
{
_container = container;
}
public IHub Create(HubDescriptor descriptor)
{
return _container.GetInstance(descriptor.HubType) as IHub;
}
}
register your custom hub activator when you´re bootstrapping your app (maybe the global.asax)
GlobalHost.DependencyResolver.Register(typeof (IHubActivator),
() => new CustomHubActivator(Container));
that´s much simplier solution rather than to configure again the signalR dependencyResolver