Isolating ASP .Net 2.0 Applications (obsolete)
|how-to | home|
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.
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
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
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.
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
web.config file needs to be modified.
To configure Win32 side-by-side for the use of ASP .Net 2.0 application:
webwhich will make the manifest name
webapp.manifest(see note below).
binfolder. 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
Releasebuild as shown above.
<configuration>section find (or add) section
<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.
In the past we were proposing to handle
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
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.
In the past we were using manifest named
web.manifest. This version of
the example HTTP module requires that the manifest be named
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.