TcpListener inherited by child processes when UseShellExecute = false

[Wizou]

i'm using .NET 2.0, and i've made a lot of tests
i've come to the conclusion that TCP servers (tcplistener), started by
a father process, are somewhat inherited by child processes if using
UseShellExecute = false

why is that ?

try it ! even if the TcpListener is started *after* the
childProcess.St art, the TCP server is still registered in netstat -ao
and connectable with telnet, even if the father process stopped (or
crashed, or was killed)
As long as the child process is living, the TCP server is there, with
the old PID of the father process
When the child process ends, the TCP server disappears and telnet
connection is stopped

This is annoying because it prevent another app from listening on this
port (for example, if you stopped debugging in Visual and you want to
restart debugging your app)

can someone explain this? or is this a bug of .NET 2.0 beta ?

thanks

[Willy Denoyette [MVP]]

"Wizou" <Wi*****@gmail. com> wrote in message
news:11******** **************@ g14g2000cwa.goo glegroups.com.. .

i'm using .NET 2.0, and i've made a lot of tests
i've come to the conclusion that TCP servers (tcplistener), started by
a father process, are somewhat inherited by child processes if using
UseShellExecute = false

why is that ?

try it ! even if the TcpListener is started *after* the
childProcess.St art, the TCP server is still registered in netstat -ao
and connectable with telnet, even if the father process stopped (or
crashed, or was killed)
As long as the child process is living, the TCP server is there, with
the old PID of the father process
When the child process ends, the TCP server disappears and telnet
connection is stopped

This is annoying because it prevent another app from listening on this
port (for example, if you stopped debugging in Visual and you want to
restart debugging your app)

can someone explain this? or is this a bug of .NET 2.0 beta ?

thanks

No, it's not a bug, it's by design.
The child process inherits all open handles of the parent process when using
Process.Start, this is the default and cannot be changed.
You can prevent this by starting the child process before you create the
TcpListerner object.

Willy.

[Wizou]

Well,

Under Windows API, you could specify, either through
SECURITY_ATTRIB UTES or through a parameter to CreateProcess if your
child processes would inherit open handles or not.
I haven't find a way to do so under .NET.
I find it a security hole that child process always have access to the
father process' handles.
(and UseShellExecute = true disables some features interesting to the
father process)

I thought *starting* the TcpListener after the child process would be
enough, but I also had to move the TcpListener object creation after
it, in order to solve my problem

Olivier

[Willy Denoyette [MVP]]

Inline

Willy.
"Wizou" <Wi*****@gmail. com> wrote in message
news:11******** **************@ o13g2000cwo.goo glegroups.com.. .

Well,

Under Windows API, you could specify, either through
SECURITY_ATTRIB UTES or through a parameter to CreateProcess if your
child processes would inherit open handles or not.
That's right, it's the CreateProcess API argument bInheritHandles that
specifies whether you want the child to inherit open handles and this is set
to true in .NET, the SECURITY_ATTRIB UTES have nothing to do with this.
I haven't find a way to do so under .NET. If you need this you wil have to call CreateProcess using PInvoke.
I find it a security hole that child process always have access to the
father process' handles. What makes you think it's a security hole?
(and UseShellExecute = true disables some features interesting to the
father process) Not sure what features you mean here. > I thought *starting* the TcpListener after the child process would be
enough, but I also had to move the TcpListener object creation after
it, in order to solve my problem No, the handle is created with the creation of the TcpClient object.

Olivier