Which event is the best for registering the types with Unity?
I wish to do this
iocContainer.RegisterType<ControllerA>();
iocContainer.RegisterType<ControllerB>();
so they could be retrieved by the ControllerFactory from the Unity Container.
My opinion was to do that in the Application_Start event, but I've been warned that I could face many problems caused by the App pool recycling (not firing the Application_start). So the alternative would be the Session_start.
Any advice?
[UPDATE]
But if I use
iocContainer.RegisterInstance<IService>(service)
what happens if the app pool recycle or IIS is resetted? Is the instance of service been recreated?
No, Application_start is the correct place to do it.
Nothing's going to help if the app pool or IIS (or the server is recycled). Then the container will be recycled itself, but when the app pool is restarted, the container will be configured anew.
I think that PreApplicationStartMethod is a better place.
Check out these articles:
http://haacked.com/archive/2010/05/16/three-hidden-extensibility-gems-in-asp-net-4.aspx
http://ilearnable.net/2010/11/22/webactivator-preapplicationstartmethod/
Related
I am currently using SignalR 2.0 and MVC 5.0 for my project. All the signalR update works fine except when I have updated the web.config file which causes the application pool to recycle. This is the starting point I notice SignalR behaving inconsistently. Sometimes I need to perform an action multiple times before the SignalR update can be propagated to the client. I have enabled the SignalR logging and I can't see anything displayed in the log whenever it failed to propagate to the client.
Do we need to do something in the hub, like reconnect or anything when the app pool got recycled?
At the moment, i didnt do anything in terms of coding and simply refresh the page. But it gives me that problems with SignalR. And the only way to fix that intermittent problem completely is to reboot the server.
Have anyone experienced this kind of behavior in SignalR?
Thanks in advance.
I have quite a slow Application_Start due to having a lot of IoC stuff happen at start up.
The problem I'm trying to solve is, how do I avoid passing that start up time to the end user?
Assumptions
My apps are hosted on AppHarbor so I have no access to IIS. However even if I did, my understudying is that it's best practice to let the app pool recycle, so there's no way to avoid having the Application_Start run regularly (I think it's every 20 minutes on AppHarbor).
My idea to solve it
Initially I thought I'd hit it every minute or something, but that seems too brute force and it may not even stop a user from experiencing the slow start up.
My current solution is to handle the Application_End event, and then immediately hit the App so that it starts up again, thus hopefully not impacting any users.
Is there a better way to solve this issue?
Unfortunately, a longer session timeout will not prevent an IIS app pool recycle when you're using InProcess session state.
Have you considered lazy loading (some of) your dependencies? SimpleInjector has documentation on how to do this, which should be adaptable to most other IoCs:
Simple Injector \ Documentation \ How To \ Register Factory Delegates \ Working With Lazy Factories
In my understanding, to prevent the propagation of startup time to users, you should avoid recycling the App Pool, for which you can use IIS App pool timeout settings,these can be tuned through web.config, not just through IIS console. Additionally you can read more of it here on this SO qurestion. You might not need Application_End hacks to achieve this.
Update :
I found another interesting thing that may help you on this, check this IIS Application Initialization Extension that can be used to preload dependencies as soon as worker process starts. It may help you improve customer experience. Check it out.
I have an ASP.NET MVC 3 application that uses Entity Framework 4.3 code first. The application works satisfactorily with the WebDev server in Visual Studio. Once the application is running in IIS 7.5, it is, it occasionally happens that the server no longer responds. The browser waits until it times out. Also, a refresh of the page does not help. Only if the browser is closed and restarted the IIS provides responses back to the browser.
The work processes are utilized here to 0%. An infinite loop is ruled out as cause therefore. When I examine the worker process with the debugger, all threads are in the external code. Even with WinDbg I can not identify the cause.
The application uses the DbContext together with the UnitOfWork pattern. The controllers receive an UnitOfWork object via dependency injection. The dependency resolution is done with the UnityDependencyResolver of the Unity.Mvc package. The Entity Framwork is also used in my own MembershipProvier and role providers, but here is the DbContext explicitly created and destroyed.
I'm desperate. What could cause this behavior?
I have a .NET 1.1 application hosted on two different servers, but on one of them whenever the application pool is recycled, all sessions are dropped.
Both applications are using “StateServer” session mode and as far as I could tell, both servers have exactly the same configuration and have the “ASP .NET State Server” service running.
This is a particularly troublesome issue, due to the fact that this application pool is recycling every 2-3 hours (that’s another issue that I have to solve).
Does anyone have any idea of might be causing this?
Thanks in advance,
Zeon
Monitor the number of active user sessions in each State Server instance with the perfom counter "State Server Sessions Active" to (a) ensure that both servers are using STate Server and (b) see that this really is caused by the app pool recycling.
It's a bit umclear from your question if these two apps share session state, or if they are two different applications, that could be important for the solution.
Anyone see any potential problems adding a FileSystemWatcher and a Timer
into my derived ServiceBase class??
Malcolm
Just be sure to wrap the events for each in a try-catch as they will run on threads from the Thread Pool. If there is an exception during the processing of that event your service may stop running unexpectedly. You should also keep the processing in the FileSystemWatcher Event to a minimum, for instance, just add the file path to a queue and then have one of your timers or Background Worker process the queue.
No. There should be no problems in using these classes in a Windows Service. Both of these classes (not sure which "Timer" class you're using) should work fine in a Service environment.
If you're running into problems, specifying those might help us figure out how to help...
We have FileSystemWatchers and timers in our derived classes. What problems are you anticipating.
I don't think so. I have used System.Threading.Timer in Windows service & its not working. After 2-3 times the code the does not work thought the service is in the running state.
Still trying to figure out the solution to the problem. If any one knows the solution, do let me know. It's driving me crazy :(