Isolating ASP .Net 2.0 Applications (obsolete)

This information is obsolete. It is included here to illustrate an approach that does not work.

See Isolating ASP .Net 2.0 Applications. for a viable solution.

How to use unregistered COM components from ASP .Net Applications

ASP .Net 1.x has built-in support for Windows unmanaged (win32) side-by-side functionality. ASP .Net 2.0 dropped that support. There is no built-in mechanism to isolate access to unmanaged resources. It is still possible to to isolate ASP .Net 2.0 applications, but some additional steps are required.

The idea is to take advantage of HTTP modules. By handling application.PreRequestHandlerExecute and application.PostRequestHandlerExecuteevents we get the opportunity to execute code before and after the ASP.Net page is processed. All we need to do is create and activate the activation context in the PreRequestHandlerExecute handler and deactivate the context in the PostRequestHandlerExecute handler. The activation context handle can be stored in the HTTP module itself and freed when the module is being destroyed. The same module will be used by multiple threads and multiple requests. This means that the activation context does not need to be created every time a new request is processed, which is good for the application performance. It also means that the activation cookie cannot be stored in the module but, instead, must be stored with the request or with the win32 thread. The example HTTP module included with Manifest Maker assumes synchronous request processing and stores the cookie in the request.

The aspnet20sample example contains an example project with an  appropriate HTTP module source code and ready to use binaries. Read more about the example.

This solution can be used with existing ASP .Net 2.0 applications including precompiled and non-updateable. No changes to the application are required, only the web.config file needs to be modified.

To configure Win32 side-by-side for the use of ASP .Net 2.0 application:

• Create a private or shared assembly (or assemblies) with the components you need to use.
• Install these assemblies on the web server; copy to a subdirectory of the application directory if private, install with MSI if shared.
• Create a private assembly referencing all the above private and shared Win32 assemblies. Name the project web which will make the manifest name webapp.manifest (see note below).
• Copy this manifest to the application directory on the server.
• Copy the HTTP activation context module to the application's bin folder. You can write your own module or you can use the module provided in Manifest Maker examples: C:\Program Files\Maze Computer\Manifest Maker\Examples\aspnet20sample\AspManifestHelpers\bin\Release\AspManifestHelpers.dll. Make sure to use the Release build as shown above.
• Edit the application's web.config file:
  • In the <configuration> section find (or add) section <httpModules>
  • in the <httpModules> section add this entry (use your names, if you used your own module):
    
    <add name="HttpModule_Manifest" type="MazeComputer.AspManifestHelpers.HttpModule_Manifest, AspManifestHelpers"/>

At this point ASP .Net will load the HTTP module and will call the appropriate handlers before and after the ASP.Net page is processed. The module provided with Manifest Maker creates the activation context on the first call then activates and deactivates it on each request. The activation context is released when the module is disposed of.

Important: The example HTTP module assumes synchronous page processing. If you explicitly turn on asynchronous processing, you must manage the context yourself. Use the example as a guideline. If you would preder to engage our consulting services, please contact us at sxs@MazeComputer.com.

Note that HTTP modules were explicitly designed for this type of additional processing and are an intrinsic part of ASP .Net 2.0.

Note:

In the past we were proposing to handle Application.BeginRequest and Application.EndRequest events to activate and deactivate the win32 activation context. That approach does not work! ASP .Net 2.0 is switching Win32 processing threads between BeginRequest and PreRequestHandlerExecute and the win32 Side-by-Side activation context remains attached to a thread we no longer have access to, while it is not active where we want it - the actual page processing code. This version of the module activates the Win32 Side-by-Side Activation Context just before page processing begins (PreRequestHandlerExecute) and deactivates it just after the page is finished (PostRequestHandlerExecute). This means that the activation context is available during the execution of your page but is not available in any HTTP modules you may have added. You need to explicitly activate and deactivate the Win32 manifest in your modules, if you need it. Just call:

 UInt32 cookie = m_ach.CreateAndActivate(file, path, out dwError);

at the beginning of your module then:

 bool bOK = m_ach.DeactivateContext(cookie, out dwError);

before you exit. See the example module for more details.

If you have a more complex case and you would prefer to engage our consulting services, please contact us at sxs@MazeComputer.com.

Also keep in mind that if you explicitly use asynchronous page processing you need to explicitly manage the activation context - this implementation assumes synchronous processing of ASP .Net requests.

You can download the updated HTTP module example using this link: sxsAspNet20.zip. This link will become invalid once we include this version of the module in the Manifest Maker installation.

Note:

In the past we were using manifest named web.manifest. This version of the example HTTP module requires that the manifest be named webapp.manifest. We encountered situations where win32 side-by-side activation context creation fails with errors indicating that web.config is invalid. This new manifest name avoids the name conflict.

Read more:

• Details on the ASP .Net 2.0 example.
• How to isolate ASP .Net 2.0 web application.
• How to isolate ASP .Net 1.x web application.
• How to isolate a native (not ASP .Net) web application.
• HTTP Modules: MSDN Magazine, May 2002
• Asynchronous Pages in ASP.NET 2.0: MSDN Magazine, October 2005