N
news
Hello,
We are having the following scenario:
A ASP.NET Application (C#) is using a managed C++ assembly, which is a thin
wrapper around an old C++ lib.
(We are using .NET framework 1.1)
In the managed C++ assembly there are some managed (gc) and some unmanaged
(nogc) classes. There is one unmanaged class (a singleton), which has a
reference (gcroot/GCHandle) to a System.Collections.Hashtable.
So the callgraph is something like this: .NET --> C++ --> .NET
Everything works fine, until ASP.NET decides to unload and reload the
AppDomain. (e.g. touching the web.config/machine.config).
If now a call is made to the component, it crashes at the point, where the
referenced Hashtable (GCHandle) is used.
I saw a few articles about this problem, including a bug report in msdn
(http://support.microsoft.com/default.aspx?scid=kb;EN-US;309694).
The bug report applies to .NET framework 1.0, so I'm wondering, if this bug
still exists in 1.1?
Is this a known bug in 1.1 too? Will the next version of the framework fix
this?
Are there any other workarounds beside the solutions in 309694.
Thanks in advance,
Hans-Jürgen.
We are having the following scenario:
A ASP.NET Application (C#) is using a managed C++ assembly, which is a thin
wrapper around an old C++ lib.
(We are using .NET framework 1.1)
In the managed C++ assembly there are some managed (gc) and some unmanaged
(nogc) classes. There is one unmanaged class (a singleton), which has a
reference (gcroot/GCHandle) to a System.Collections.Hashtable.
So the callgraph is something like this: .NET --> C++ --> .NET
Everything works fine, until ASP.NET decides to unload and reload the
AppDomain. (e.g. touching the web.config/machine.config).
If now a call is made to the component, it crashes at the point, where the
referenced Hashtable (GCHandle) is used.
I saw a few articles about this problem, including a bug report in msdn
(http://support.microsoft.com/default.aspx?scid=kb;EN-US;309694).
The bug report applies to .NET framework 1.0, so I'm wondering, if this bug
still exists in 1.1?
Is this a known bug in 1.1 too? Will the next version of the framework fix
this?
Are there any other workarounds beside the solutions in 309694.
Thanks in advance,
Hans-Jürgen.