AppDomains and static unmanaged variables

[Stephen Walch]

Our application environment consists of three basic layers:

1. Third-party unmanaged DLLs that were written before the CLR was invented
and maintain a significant amount of information (including memory
management and connection pooling constructs) as static variables which were
intended to scoped to the process.

2. Managed C++ assemblies (.NET 1.1) that wrap the unmanaged DLLs as nice
neat classes with managed interfaces.

3. ASP.NET 1.1 applications that call the managed assemblies.

When running just one ASP.NET web app, everything is fine, even with
high-volume multi-threaded access. But introduce a second web app in the
same AppPool, and eventually the state of the unmanaged DLLs in #1 become
corrupted. The only explanation I can come up with is that calling the
unmanaged DLLs from multiple AppDomains is breaking the assumption that the
original developers made that static variable are global to the process.

Is there a good solution to this problem? Perhaps a way to force static
variables to be global in a process again? Or am I misunderstanding what
might be going on?

 

[Steven Cheng[MSFT]]

Hello Stephen,

Based on your description, my understanding on your problem is that you
have an ASP.NET web application which uses a managed C++ component library
that act as a wrapper of an unmanaged c++ dll. This application works well
when there is only single web application work in the Application Pool, but
get messed state management when running multiple web applications in the
same application pool(IIS), correct?

As you mentioned that the C++ unmanaged dll uses some static variables to
manage global connection pool(or other states), I think this should be the
cause of the problem. As for ASP.NET(or other .net framework/clr based
application), it is running at AppDomain based boundary, that means global
variables(static class members in .net applications) is only visible in its
own AppDomain, not in the entire host process(which is different from the
variable sharing scope for win32 application---process based scope).

For your scenario, in IIS6, all the ASP.NET applications (which use the
same App Pool) will be hosted in the same worker process, therefore, if
you've used any unmanaged c++ code which use global variables, they'll be
accessible by all the applications in the worker process no matter they're
in the same AppDomain or not. Therefore, I'm wondering whether it is
possible that you'll configure those applications to use separate
application pool(in IIS) if they'll access the same win32/c++ global
variables? So far this is the only means I can get to prevent the win32/
c++ global variables to be accessed by multiple applications.

Please feel free to let me know if you have any other concerns or ideas on
this.


Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.



Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================



This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Stephen Walch]

Yes you have correctly restated the problem.

In my testing, resorting to the workaround you described (putting the web
apps in different AppPools, and thus different processes) does fix the
problem. In real life, however, this is not an option in a few cases. One
important case is SharePoint, where the site and the _layouts pages are
implemented as separate web apps, but (as far as I can tell) they need to be
in the same AppPool. I tried putting them in a separate AppPools and this
broke the SharePoint site.

I cannot recode the unmanaged DLL, as it was written by a third party. So
my only choice is to code some protection into my wrapper classes. For
example, is there a way to force all accesses to my wrapper class (or
wrapper assembly) to be marshaled over to a singleton AppDomain?

In the old COM days, when threading was our biggest problem, we has
apartment models to protect legacy code that code not handle
multi-threading. Is there nothing to protect legacy code that does not
understand about AppDomains?

Thanks!

 

[Steven Cheng[MSFT]]

Thanks for your reply Stephen,

Yes, for unmanaged c++ component, the managed appdomain has no sense of the
global variables so that it can not determine whether the access is proper.
So far I haven't found any good means to marshal such unmanaged calls to be
STA like. I'll help you consult some other IIS and .NET engineers to see
whether there is any possible workaround. I'll update you as soon as
possible.


Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Steven Cheng[MSFT]]

Hello Stephen,

After some further discussion with some other .net engineers, I'm afraid so
far we haven't any better means to adjust the behavior at .net layer. This
is because no matter how to do in our managed wrapper class, the undelrying
unmanaged dll do not have sense of .NET application boundary(AppDomain), it
will always react to method calls from different calling managed appdomain
as the same ones and thus the problem still remains.

If you do feel this any urgent issue, I would suggest you consider contact
CSS for further assistance due to the restriction of newsgroup support.

Please feel free to let me know if there is anything else we can help.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.