In ASP.NET WebAPI there is a method called ApplicationStart in the global.asax.cs file which is automagically called when the application started. How is this called?
The reason I ask is I would like to add an Application_End method to do any cleanup I need to do.
ASP.NET WebApi is no different than ASP.NET when it comes to the Global.asax methods. These methods are discovered via reflection by the IIS application pool worker when the application is loaded and are then invoked at the appropriate times. There is a nice overview of this on MSDN, particularly the Global.asax methods like Application_Start() and Application_End().
Application_Start() is called by IIS when the application starts running inside the application pool. Generally, this happens when a request comes in for a resource within the application's domain. After all, the application has to be running for the request to be serviced.
Application_End() is called just before the application is unloaded or just before the application pool recycles. There are various triggers that cause the application pool to recycle.
MSDN has the full details here - http://msdn.microsoft.com/en-us/library/ms178473(v=vs.100).aspx, but the key bit that your interested in is:
Application_Start ..... Called when the first resource (such as a page) in an ASP.NET application is requested. The Application_Start method is called only one time during the life cycle of an application. You can use this method to perform startup tasks such as loading data into the cache and initializing static values.
Essentially it is invoked once per application life-cycle automatically by the application container (e.g. IIS).
Related
I have created a new web api project and along with it there is the WeatherForecast controller with a GET method.
I want to ask - what is the scope of the controller class?
Since I don't find any Dependency injection setup for controller, is it by default singleton or scoped?
The scope of a controller in all ASP.NET stacks since ASP.NET MVC 1.0 is the request - a new Controller instance is created by the ASP.NET middleware to handle each request.
The ASP.NET Core middleware pipeline is pretty deep though, and controller instances are only created in the last stage, in the Endpoint middleware.
They controller and the action that handles the request are the User Code box in the endpoint pipelines
You'll have to assume that the controller will be disposed very soon after an action method finishes processing a request. It won't be safe to access a controller instance from any other class after that point, even other scoped classes.
If you want to share data you'll have to store it in some other place, eg the Session, a cache, use common Options objects, a singleton Dictionary (essentially a cache), a database etc.
I am using a shared process engine on WebSphere and I want to understand how the engine looks up the required resources (custom code shipped with my process application) for a process step invocation. Is a thread context switch applied?
The shared process engine can be used by multiple applications, one of these applications being the Camunda webapplication.
Whenever the process engine "does something" within a process instance, such as executing a service task, it performs a Thread Context Switch. This Thread Context Switch is performed to the application which deployed the BPMN process that the engine is currently executing. This is necessary for the process engine to be able to use resources locally available within that application.
Examples for these kinds of resources:
The application's classloader, in order to instantiate Java Delegates
The application's CDI Bean Manager, in order to be able to invoke CDI Beans.
How does this "Thread Context Switch" work technically?
The process engine executes a callback method on an EJB which has to be included within the application. This is why you include the camunda-ejb-client.jar. Relevant information: the process engine invokes the local business interface of that EJB.
As a result, the Thread Context Switch is performed with EJB local invocation semantics. Whatever Websphere puts in place for an EJB local invocation will work and whatever Websphere does not put in place for an EJB local invocation will not work.
The behavior is exactly the same as it would be if you would put the code from your Java Delegates into an EJB with a local business interface and invoke that from another application.
The latest version of SimpleInjector introduced a distinction between MVC and WebApi. Are the two request registrations aliases for the same thing? Or is there underlying differences as well?
Thanks
The lifestyles and scope implementations WebRequest and WebApiRequest in SimpleInjector 2.5 are based on different technologies.
WebApiRequestLifestyle is derived from ExecutionContextScopeLifestyle which works well both inside and outside of IIS. I.e. it can function in a self-hosted WebAPI project where there is no HttpContext.Current. The scope used by WebApiRequestLifestyle is ExecutionContextScope. As the name implies an ExecutionContextScope registers itself in the logical call context and flows with async operations across threads (e.g. a continuation after await on a different thread still has access to the scope regardless of whether ConfigureAwait() was used with true or false).
In contrast, an instance of WebRequestLifestyle is stored within the HttpContext. The HttpContext can be used with WebAPI when it is hosted in IIS but care must be taken because it will not always flow with the execution context because the current HttpContext is stored in the IllogicalCallContext (see Understanding SynchronizationContext in ASP.NET). If you use await with ConfigureAwait(false) the continuation may lose track of the original HttpContext whenever the async-op does not execute synchronously. A direct effect of this is that it would no longer be possible to resolve the instance of a previously created service with WebRequestLifestyle from the container (e.g. in a factory that has access to the container) - and an exception would be thrown because HttpContext.Current would be null.
I would recommend you use WebApiRequestLifestyle for services that should be 'per Web API request', the most obvious example being services that are injected into WebAPI controllers. WebApiRequestLifestyle offers the following benefits:
the WebAPI controller can be used outside of IIS (e.g. in a self-hosted project)
the WebAPI controller can execute free-threaded (or multi-threaded) async methods because it is not limited to the ASP.net SynchronizationContext.
Check out the blog entry of Stephen Toub regarding the difference between ExecutionContext and SynchronizationContext.
I have just installed Visual Studio 2013, created an MVC Web Application project and noticed a new file in the project template called Startup.cs.
What is this, how is this different from Global.asax.cs and are there any good best practices on what to use this for?
Every OWIN application has a startup class where you specify components for the application pipeline.
If you start a new Visual Studio project, you'll see pieces of OWIN in it.
OWIN is a specification that defines an API for framework and servers to cooperation.
The point of OWIN is to decouple server and application.
For example, ASP.NET Identity uses OWIN security, SignalR self hosting uses OWIN hosting, and etc., the examples all use OWIN,
therefore they all need to have a startup class, that is defined in "Startup.cs" file.
The Global.asax, the ASP.NET application file, is an optional file that contains code for responding
to application-level events raised by ASP.NET or by HttpModules.
For more details:
OWIN
http://www.asp.net/aspnet/overview/owin-and-katana
Global.asax
http://msdn.microsoft.com/en-us/library/1xaas8a2(v=vs.71).aspx
You can find more ideas about why OWIN in the following article:
http://www.asp.net/aspnet/overview/owin-and-katana/an-overview-of-project-katana
The file seems to be related to SignalR. Quoting the VS 2013 release notes:
Built on OWIN
SignalR 2.0 is built completely on OWIN (the Open Web Interface for
.NET). This change makes the setup process for SignalR much more
consistent between web-hosted and self-hosted SignalR applications,
but has also required a number of API changes.
MapHubs and MapConnection are now MapSignalR
For compatibility with OWIN standards, these methods have been renamed
to MapSignalR. MapSignalR called without parameters will map all hubs
(as MapHubs does in version 1.x); to map individual
PersistentConnection objects, specify the connection type as the type
parameter, and the URL extension for the connection as the first
argument.
The MapSignalR method is called in an Owin startup class. Visual
Studio 2013 contains a new template for an Owin startup class; to use
this template, do the following:
Right-click on the project
Select Add, New Item...
Select Owin Startup class. Name the new class Startup.cs.
In a Web application, the Owin startup class containing the MapSignalR
method is then added to Owin's startup process using an entry in the
application settings node of the Web.Config file, as shown below.
In a Self-hosted application, the Startup class is passed as the type
parameter of the WebApp.Start method.
The Startup class is the convention that Katana/OWIN looks for to initialize the pipeline. When your app starts, the code inside of the Configuration function is run to set up the components that'll be used. In the MVC 5 templates, it's used to wire up the authentication middleware which is all built on top of OWIN.
If you want to use dependency injection with OWIN, check out this project on GitHub: DotNetDoodle.Owin.Dependencies
A bit of a strange situation: I'm developing an ASP.NET MVC 3 application that uses Autofac as its IoC container and that can be dropped into any existing MVC or WebForms application.
Everything works fine, except when the other application also uses Autofac. I've created a custom DependencyResolver wrapper that combines my application's AutofacDependencyResolver with DependencyReolver.Current of the other application (when set). Resolving of components just fails sometimes although I can see in the debugger that everything is properly registered.
I suspect that both inner resolvers are competing for a spot in the HttpContext.Items collection, but I can't get my finger behind the exact issue.
What would be the proper way to handle this situation?
You could isolate the configuration into a module. When you integrate one application into the other, register the module.