Threads created in unmanaged code always use the default app domai

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,
I have developed an application that uses mixed C++ to integrate managed
..NET applications with an unmanaged C++ application whose behaviour I cannot
change.

The unmanaged C++ application uses the Win32 API's CreateThread fn to create
a thread that listens for requests. These requests then call into the mixed
C++ code. This all works fine when the application lives in the same app
domain.

However, in an environment such as IIS where the application lives in its
own app domain there is a problem because the thread that is being created in
the unmanaged code is using the default app domain and so cannot use the
objects created in the application's app domain. Is there anyway to get these
threads to use the applications app domain rather than the default app domain?

In my opinion this behaviour is a bug, I thought that the whole idea of an
app domain was to create a sandbox where by the main application (in this
case IIS) could run numerous applications without having to worry about their
behaviour. Yet using this method I have a thread running in the default app
domain which I assume would have the capability to bring down IIS.
Cheers,
Paul
 
Paul said:
Hi,
I have developed an application that uses mixed C++ to integrate managed
..NET applications with an unmanaged C++ application whose behaviour I cannot
change.

The unmanaged C++ application uses the Win32 API's CreateThread fn to create
a thread that listens for requests. These requests then call into the mixed
C++ code. This all works fine when the application lives in the same app
domain.

However, in an environment such as IIS where the application lives in its
own app domain there is a problem because the thread that is being created in
the unmanaged code is using the default app domain and so cannot use the
objects created in the application's app domain. Is there anyway to get these
threads to use the applications app domain rather than the default app domain?

In my opinion this behaviour is a bug, I thought that the whole idea of an
app domain was to create a sandbox where by the main application (in this
case IIS) could run numerous applications without having to worry about their
behaviour. Yet using this method I have a thread running in the default app
domain which I assume would have the capability to bring down IIS.
Cheers,
Paul
Click to expand...
Create the thread on the managed side.

Ronald Laeremans'
Visual C++ team
 
Hi Ronald,
As I said in my original post I am integrating with a legacy unmanaged C++
application that I have no control of so it is not possible for me to create
the thread on the managed side. Is this the only way to work around this
issue?
By the way is there a bug number or something associated with this? Is it
considered a bug?? Is it likely to be fixed?
Cheers,
Paul


--
Paul Kenny
Senior Software Engineer
IONA Technologies Plc.
 
Paul said:
Hi Ronald,
As I said in my original post I am integrating with a legacy unmanaged C++
application that I have no control of so it is not possible for me to create
the thread on the managed side. Is this the only way to work around this
issue?
By the way is there a bug number or something associated with this? Is it
considered a bug?? Is it likely to be fixed?
Cheers,
Paul
Click to expand...
You can also use the .NET hosting APIs to get significantly more fine
grained control from the native side. You can take a look here for the
2.0 version of the hosting API:
http://winfx.msdn.microsoft.com/lib...html/703b8381-43db-4a4d-9faa-cca39302d922.asp

Ronald
 
Back
Top