473,386 Members | 1,886 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,386 software developers and data experts.

Process.Start and Console Window Issue

When one uses the System.Diagnostics.Process.Start method to launch a common
or garden Console application, one can set the WindowStyle property of the
StartInfo object to ProcessWindowStyle.Hidden so that the window for the
Console application is not visible.

However, when using some of the 'advanced' properties of the StartInfo
object, like Username, Password and Domain, the WindowsStyle property of the
StartInfo object is ignored. (This is because the Process.Start method makes
a call to CreateProcess (or one of it's variants) intead of the 'normal'
call to ShellExecuteEx.)

Unfortunately this results in the Console application window being shown
which looks ugly.

The effect of this can be somewhat mitigated by making the window of the
calling application 'TopMost' for the life of the Console application which,
at least, makes the Console application window appear behind the window of
the calling application.

Has anyone who has encountered this 'issue' managed to find a way to 'hide'
the Console application window under this scenario?

Mar 13 '07 #1
10 1573
On Mar 13, 5:36 pm, "Stephany Young" <noone@localhostwrote:
When one uses the System.Diagnostics.Process.Start method to launch a common
or garden Console application, one can set the WindowStyle property of the
StartInfo object to ProcessWindowStyle.Hidden so that the window for the
Console application is not visible.

However, when using some of the 'advanced' properties of the StartInfo
object, like Username, Password and Domain, the WindowsStyle property of the
StartInfo object is ignored. (This is because the Process.Start method makes
a call to CreateProcess (or one of it's variants) intead of the 'normal'
call to ShellExecuteEx.)

Unfortunately this results in the Console application window being shown
which looks ugly.

The effect of this can be somewhat mitigated by making the window of the
calling application 'TopMost' for the life of the Console application which,
at least, makes the Console application window appear behind the window of
the calling application.

Has anyone who has encountered this 'issue' managed to find a way to 'hide'
the Console application window under this scenario?

This probably isn't perfect, but with your abilities you should be
able to adapt it to fit your needs.

This is the code for a form with one button named Button1 - it uses
the FindWindow and ShowWindow APIs:

Public Class Form1

Private Sub Form1_Load(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Me.Load
Process.Start("C:\ConsoleApplication1.exe")
End Sub

<System.Runtime.InteropServices.DllImport("user32" )_
Public Shared Sub ShowWindow(ByVal hWnd As IntPtr, ByVal nCmdShow
As Int32)
End Sub

<System.Runtime.InteropServices.DllImport("user32" )_
Public Shared Function FindWindow(ByVal lpClassName As String,
ByVal lpWindowname As String) As IntPtr
End Function

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles Button1.Click
Dim hWnd As IntPtr = FindWindow(Nothing, "C:
\ConsoleApplication1.exe")
ShowWindow(hWnd, 0)
End Sub

End Class

I hope this helps you out!

Thanks,

Seth Rowe
Mar 14 '07 #2
Thanks for that Seth.

The console application is question is one that is short lived, takes
command line arguments and doesn't 'do' interactive input/output.

A call to ShowWindow fails because the console application window has been
and gone before the code in the calling application can deal with it.

It is the console application window appearing and disappearing that makes
it look ugly.
"rowe_newsgroups" <ro********@yahoo.comwrote in message
news:11**********************@n76g2000hsh.googlegr oups.com...
On Mar 13, 5:36 pm, "Stephany Young" <noone@localhostwrote:
>When one uses the System.Diagnostics.Process.Start method to launch a
common
or garden Console application, one can set the WindowStyle property of
the
StartInfo object to ProcessWindowStyle.Hidden so that the window for the
Console application is not visible.

However, when using some of the 'advanced' properties of the StartInfo
object, like Username, Password and Domain, the WindowsStyle property of
the
StartInfo object is ignored. (This is because the Process.Start method
makes
a call to CreateProcess (or one of it's variants) intead of the 'normal'
call to ShellExecuteEx.)

Unfortunately this results in the Console application window being shown
which looks ugly.

The effect of this can be somewhat mitigated by making the window of the
calling application 'TopMost' for the life of the Console application
which,
at least, makes the Console application window appear behind the window
of
the calling application.

Has anyone who has encountered this 'issue' managed to find a way to
'hide'
the Console application window under this scenario?


This probably isn't perfect, but with your abilities you should be
able to adapt it to fit your needs.

This is the code for a form with one button named Button1 - it uses
the FindWindow and ShowWindow APIs:

Public Class Form1

Private Sub Form1_Load(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Me.Load
Process.Start("C:\ConsoleApplication1.exe")
End Sub

<System.Runtime.InteropServices.DllImport("user32" )_
Public Shared Sub ShowWindow(ByVal hWnd As IntPtr, ByVal nCmdShow
As Int32)
End Sub

<System.Runtime.InteropServices.DllImport("user32" )_
Public Shared Function FindWindow(ByVal lpClassName As String,
ByVal lpWindowname As String) As IntPtr
End Function

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles Button1.Click
Dim hWnd As IntPtr = FindWindow(Nothing, "C:
\ConsoleApplication1.exe")
ShowWindow(hWnd, 0)
End Sub

End Class

I hope this helps you out!

Thanks,

Seth Rowe

Mar 14 '07 #3
On Mar 13, 8:35 pm, "Stephany Young" <noone@localhostwrote:
Thanks for that Seth.

The console application is question is one that is short lived, takes
command line arguments and doesn't 'do' interactive input/output.

A call to ShowWindow fails because the console application window has been
and gone before the code in the calling application can deal with it.

It is the console application window appearing and disappearing that makes
it look ugly.

"rowe_newsgroups" <rowe_em...@yahoo.comwrote in message

news:11**********************@n76g2000hsh.googlegr oups.com...
On Mar 13, 5:36 pm, "Stephany Young" <noone@localhostwrote:
When one uses the System.Diagnostics.Process.Start method to launch a
common
or garden Console application, one can set the WindowStyle property of
the
StartInfo object to ProcessWindowStyle.Hidden so that the window for the
Console application is not visible.
However, when using some of the 'advanced' properties of the StartInfo
object, like Username, Password and Domain, the WindowsStyle property of
the
StartInfo object is ignored. (This is because the Process.Start method
makes
a call to CreateProcess (or one of it's variants) intead of the 'normal'
call to ShellExecuteEx.)
Unfortunately this results in the Console application window being shown
which looks ugly.
The effect of this can be somewhat mitigated by making the window of the
calling application 'TopMost' for the life of the Console application
which,
at least, makes the Console application window appear behind the window
of
the calling application.
Has anyone who has encountered this 'issue' managed to find a way to
'hide'
the Console application window under this scenario?
This probably isn't perfect, but with your abilities you should be
able to adapt it to fit your needs.
This is the code for a form with one button named Button1 - it uses
the FindWindow and ShowWindow APIs:
Public Class Form1
Private Sub Form1_Load(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Me.Load
Process.Start("C:\ConsoleApplication1.exe")
End Sub
<System.Runtime.InteropServices.DllImport("user32" )_
Public Shared Sub ShowWindow(ByVal hWnd As IntPtr, ByVal nCmdShow
As Int32)
End Sub
<System.Runtime.InteropServices.DllImport("user32" )_
Public Shared Function FindWindow(ByVal lpClassName As String,
ByVal lpWindowname As String) As IntPtr
End Function
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles Button1.Click
Dim hWnd As IntPtr = FindWindow(Nothing, "C:
\ConsoleApplication1.exe")
ShowWindow(hWnd, 0)
End Sub
End Class
I hope this helps you out!
Thanks,
Seth Rowe
Sorry it didn't help.

Can you rewrite the console application or does the "hide" code have
to be in the calling program?

Thanks,

Seth Rowe

Mar 14 '07 #4
Rewriting the console application is not an option. It is actually
RegAsm.exe.

Without going into the why's and wherefore's, I need an ordinary user to be
able to unregister a .NET assembly that exposes COM objects and to register
a new version.

The customer's security policy does not allow an ordinary user to have any
more than read access to HKEY_CLASSES_ROOT otherwise it would not be an
issue.

The pertinent code can happily launch RegAsm.exe with the necessary
credentials so the the unregister/register can occur but each 'launch' of
RegAsm.exe results in the ugly console window appearing and disappearing as
I described earlier.

The functionality is NOT an issue. The issue is purely from the visual
asthetics angle.
"rowe_newsgroups" <ro********@yahoo.comwrote in message
news:11**********************@e65g2000hsc.googlegr oups.com...
On Mar 13, 8:35 pm, "Stephany Young" <noone@localhostwrote:
>Thanks for that Seth.

The console application is question is one that is short lived, takes
command line arguments and doesn't 'do' interactive input/output.

A call to ShowWindow fails because the console application window has
been
and gone before the code in the calling application can deal with it.

It is the console application window appearing and disappearing that
makes
it look ugly.

"rowe_newsgroups" <rowe_em...@yahoo.comwrote in message

news:11**********************@n76g2000hsh.googleg roups.com...
On Mar 13, 5:36 pm, "Stephany Young" <noone@localhostwrote:
When one uses the System.Diagnostics.Process.Start method to launch a
common
or garden Console application, one can set the WindowStyle property of
the
StartInfo object to ProcessWindowStyle.Hidden so that the window for
the
Console application is not visible.
>However, when using some of the 'advanced' properties of the StartInfo
object, like Username, Password and Domain, the WindowsStyle property
of
the
StartInfo object is ignored. (This is because the Process.Start method
makes
a call to CreateProcess (or one of it's variants) intead of the
'normal'
call to ShellExecuteEx.)
>Unfortunately this results in the Console application window being
shown
which looks ugly.
>The effect of this can be somewhat mitigated by making the window of
the
calling application 'TopMost' for the life of the Console application
which,
at least, makes the Console application window appear behind the
window
of
the calling application.
>Has anyone who has encountered this 'issue' managed to find a way to
'hide'
the Console application window under this scenario?
This probably isn't perfect, but with your abilities you should be
able to adapt it to fit your needs.
This is the code for a form with one button named Button1 - it uses
the FindWindow and ShowWindow APIs:
Public Class Form1
Private Sub Form1_Load(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Me.Load
Process.Start("C:\ConsoleApplication1.exe")
End Sub
<System.Runtime.InteropServices.DllImport("user32" )_
Public Shared Sub ShowWindow(ByVal hWnd As IntPtr, ByVal nCmdShow
As Int32)
End Sub
<System.Runtime.InteropServices.DllImport("user32" )_
Public Shared Function FindWindow(ByVal lpClassName As String,
ByVal lpWindowname As String) As IntPtr
End Function
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles Button1.Click
Dim hWnd As IntPtr = FindWindow(Nothing, "C:
\ConsoleApplication1.exe")
ShowWindow(hWnd, 0)
End Sub
End Class
I hope this helps you out!
Thanks,
Seth Rowe

Sorry it didn't help.

Can you rewrite the console application or does the "hide" code have
to be in the calling program?

Thanks,

Seth Rowe
Mar 14 '07 #5
Stephany Young wrote:
When one uses the System.Diagnostics.Process.Start method to launch a common
or garden Console application, one can set the WindowStyle property of the
StartInfo object to ProcessWindowStyle.Hidden so that the window for the
Console application is not visible.

However, when using some of the 'advanced' properties of the StartInfo
object, like Username, Password and Domain, the WindowsStyle property of the
StartInfo object is ignored. (This is because the Process.Start method makes
a call to CreateProcess (or one of it's variants) intead of the 'normal'
call to ShellExecuteEx.)
<snip>
Has anyone who has encountered this 'issue' managed to find a way to 'hide'
the Console application window under this scenario?
Since you can't control the console app, maybe you can launch a second
instance of your own app with the necessary credentials and this
second instance in turn launches the console app -- without the need
to specify username and password, since the credentials would be
already in place (or so I guess):

<aircode>
Private STR_CMDLINE = "/launch"

Sub LaunchApp(Application As String, _
Args As String, _
Optional ByVal Login As String = Nothing, _
Optional ByVal Pwd As SecureString = Nothing)

Dim Info As New ProcessStartInfo

If Login IsNot Nothing Then
'Relaunches itself with special cmdline
Info.FileName = Application.ExecutablePath
Info.Arguments = String.Format("{0} {1} {2}", _
STR_CMDLINE, Application, Args)
Info.UserName = Login
Info.Password = Pwd
Info.UseShellExecute = False

Else
'Launches the desired application
Info.FileName = Application
Info.Arguments = Args
Info.WindowStyle = ProcessWindowStyle.Hidden
End If

Dim P As Process = Process.Start(Info)
P.WaitForExit(MAX_WAIT)
End Sub

Sub MainForm_Load(...) Handles MainForm.Load

With My.Application.CommandLineArgs

'Verifies if called with special cmdline arg
'and if so, hides the main window and launches
'the specified app

If .Count 0 AndAlso _
.Item(0) = STR_CMDLINE Then
Me.Visible = False
Dim App As String = .Item(1)
Dim S As New System.Text.StringBuilder
For Index As Integer = 2 to .Count-1
S.Append(.Item(Index))
S.Append(" "c)
Next
LaunchApp(App, S.ToString)
Close
Return
End If
End With

'... continue with default loading
End Sub
</aircode>

HTH.

Regards,

Branco.

Mar 14 '07 #6
Thanks for your input Branco.

I've tried that and unfortunately it doesn't work, (although one might
reasonably have an expectation that it should).

The executable launched with the Process.Start method runs in the security
of the logged in user even if the piece of code that launched it is elevated
by way of impersonation or other means.
"Branco Medeiros" <br*************@gmail.comwrote in message
news:11**********************@p15g2000hsd.googlegr oups.com...
Stephany Young wrote:
>When one uses the System.Diagnostics.Process.Start method to launch a
common
or garden Console application, one can set the WindowStyle property of
the
StartInfo object to ProcessWindowStyle.Hidden so that the window for the
Console application is not visible.

However, when using some of the 'advanced' properties of the StartInfo
object, like Username, Password and Domain, the WindowsStyle property of
the
StartInfo object is ignored. (This is because the Process.Start method
makes
a call to CreateProcess (or one of it's variants) intead of the 'normal'
call to ShellExecuteEx.)
<snip>
>Has anyone who has encountered this 'issue' managed to find a way to
'hide'
the Console application window under this scenario?

Since you can't control the console app, maybe you can launch a second
instance of your own app with the necessary credentials and this
second instance in turn launches the console app -- without the need
to specify username and password, since the credentials would be
already in place (or so I guess):

<aircode>
Private STR_CMDLINE = "/launch"

Sub LaunchApp(Application As String, _
Args As String, _
Optional ByVal Login As String = Nothing, _
Optional ByVal Pwd As SecureString = Nothing)

Dim Info As New ProcessStartInfo

If Login IsNot Nothing Then
'Relaunches itself with special cmdline
Info.FileName = Application.ExecutablePath
Info.Arguments = String.Format("{0} {1} {2}", _
STR_CMDLINE, Application, Args)
Info.UserName = Login
Info.Password = Pwd
Info.UseShellExecute = False

Else
'Launches the desired application
Info.FileName = Application
Info.Arguments = Args
Info.WindowStyle = ProcessWindowStyle.Hidden
End If

Dim P As Process = Process.Start(Info)
P.WaitForExit(MAX_WAIT)
End Sub

Sub MainForm_Load(...) Handles MainForm.Load

With My.Application.CommandLineArgs

'Verifies if called with special cmdline arg
'and if so, hides the main window and launches
'the specified app

If .Count 0 AndAlso _
.Item(0) = STR_CMDLINE Then
Me.Visible = False
Dim App As String = .Item(1)
Dim S As New System.Text.StringBuilder
For Index As Integer = 2 to .Count-1
S.Append(.Item(Index))
S.Append(" "c)
Next
LaunchApp(App, S.ToString)
Close
Return
End If
End With

'... continue with default loading
End Sub
</aircode>

HTH.

Regards,

Branco.
Mar 14 '07 #7
Never tried but another option could be to look around :
http://msdn2.microsoft.com/en-us/lib...rassembly.aspx

The idea is that most of .NET utilities are not created from scratch but are
using actually .NET framework classes to implement their functionality...

Also I remember to have seen something about no touch COM registration.
Don't know if it could apply also to registering .NET assemblies or if it is
devoted to "true" COM classes.

Also it could be perpaps possible to consider some alternative such as
perhaps registering once for all a .NET "proxy" that will load in turn the
appropriate version making useless to unregister/reregister different .NET
assemblies.

You could also perhaps impersonate in code so that ProcessStart retains your
options....

--
Patrice

"Stephany Young" <noone@localhosta écrit dans le message de news:
e1**************@TK2MSFTNGP06.phx.gbl...
Rewriting the console application is not an option. It is actually
RegAsm.exe.

Without going into the why's and wherefore's, I need an ordinary user to
be able to unregister a .NET assembly that exposes COM objects and to
register a new version.

The customer's security policy does not allow an ordinary user to have any
more than read access to HKEY_CLASSES_ROOT otherwise it would not be an
issue.

The pertinent code can happily launch RegAsm.exe with the necessary
credentials so the the unregister/register can occur but each 'launch' of
RegAsm.exe results in the ugly console window appearing and disappearing
as I described earlier.

The functionality is NOT an issue. The issue is purely from the visual
asthetics angle.
"rowe_newsgroups" <ro********@yahoo.comwrote in message
news:11**********************@e65g2000hsc.googlegr oups.com...
>On Mar 13, 8:35 pm, "Stephany Young" <noone@localhostwrote:
>>Thanks for that Seth.

The console application is question is one that is short lived, takes
command line arguments and doesn't 'do' interactive input/output.

A call to ShowWindow fails because the console application window has
been
and gone before the code in the calling application can deal with it.

It is the console application window appearing and disappearing that
makes
it look ugly.

"rowe_newsgroups" <rowe_em...@yahoo.comwrote in message

news:11**********************@n76g2000hsh.google groups.com...

On Mar 13, 5:36 pm, "Stephany Young" <noone@localhostwrote:
When one uses the System.Diagnostics.Process.Start method to launch a
common
or garden Console application, one can set the WindowStyle property
of
the
StartInfo object to ProcessWindowStyle.Hidden so that the window for
the
Console application is not visible.

However, when using some of the 'advanced' properties of the
StartInfo
object, like Username, Password and Domain, the WindowsStyle property
of
the
StartInfo object is ignored. (This is because the Process.Start
method
makes
a call to CreateProcess (or one of it's variants) intead of the
'normal'
call to ShellExecuteEx.)

Unfortunately this results in the Console application window being
shown
which looks ugly.

The effect of this can be somewhat mitigated by making the window of
the
calling application 'TopMost' for the life of the Console application
which,
at least, makes the Console application window appear behind the
window
of
the calling application.

Has anyone who has encountered this 'issue' managed to find a way to
'hide'
the Console application window under this scenario?

This probably isn't perfect, but with your abilities you should be
able to adapt it to fit your needs.

This is the code for a form with one button named Button1 - it uses
the FindWindow and ShowWindow APIs:

Public Class Form1

Private Sub Form1_Load(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Me.Load
Process.Start("C:\ConsoleApplication1.exe")
End Sub

<System.Runtime.InteropServices.DllImport("user32" )_
Public Shared Sub ShowWindow(ByVal hWnd As IntPtr, ByVal nCmdShow
As Int32)
End Sub

<System.Runtime.InteropServices.DllImport("user32" )_
Public Shared Function FindWindow(ByVal lpClassName As String,
ByVal lpWindowname As String) As IntPtr
End Function

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles Button1.Click
Dim hWnd As IntPtr = FindWindow(Nothing, "C:
\ConsoleApplication1.exe")
ShowWindow(hWnd, 0)
End Sub

End Class

I hope this helps you out!

Thanks,

Seth Rowe

Sorry it didn't help.

Can you rewrite the console application or does the "hide" code have
to be in the calling program?

Thanks,

Seth Rowe

Mar 14 '07 #8
The "free registration" thing I saw seems to have also a .NET assembly
activation counterpart that is at :
http://msdn2.microsoft.com/en-us/library/ms973915.aspx

Didn't had time to give this a close look but it seems to show how a win32
client could call a.NET assembly through COM without requiring
registration...

"Patrice" <http://www.chez.com/scribe/a écrit dans le message de news:
e6**************@TK2MSFTNGP06.phx.gbl...
Never tried but another option could be to look around :
http://msdn2.microsoft.com/en-us/lib...rassembly.aspx

The idea is that most of .NET utilities are not created from scratch but
are using actually .NET framework classes to implement their
functionality...

Also I remember to have seen something about no touch COM registration.
Don't know if it could apply also to registering .NET assemblies or if it
is devoted to "true" COM classes.

Also it could be perpaps possible to consider some alternative such as
perhaps registering once for all a .NET "proxy" that will load in turn the
appropriate version making useless to unregister/reregister different .NET
assemblies.

You could also perhaps impersonate in code so that ProcessStart retains
your options....

--
Patrice

"Stephany Young" <noone@localhosta écrit dans le message de news:
e1**************@TK2MSFTNGP06.phx.gbl...
>Rewriting the console application is not an option. It is actually
RegAsm.exe.

Without going into the why's and wherefore's, I need an ordinary user to
be able to unregister a .NET assembly that exposes COM objects and to
register a new version.

The customer's security policy does not allow an ordinary user to have
any more than read access to HKEY_CLASSES_ROOT otherwise it would not be
an issue.

The pertinent code can happily launch RegAsm.exe with the necessary
credentials so the the unregister/register can occur but each 'launch'
of RegAsm.exe results in the ugly console window appearing and
disappearing as I described earlier.

The functionality is NOT an issue. The issue is purely from the visual
asthetics angle.
"rowe_newsgroups" <ro********@yahoo.comwrote in message
news:11**********************@e65g2000hsc.googleg roups.com...
>>On Mar 13, 8:35 pm, "Stephany Young" <noone@localhostwrote:
Thanks for that Seth.

The console application is question is one that is short lived, takes
command line arguments and doesn't 'do' interactive input/output.

A call to ShowWindow fails because the console application window has
been
and gone before the code in the calling application can deal with it.

It is the console application window appearing and disappearing that
makes
it look ugly.

"rowe_newsgroups" <rowe_em...@yahoo.comwrote in message

news:11**********************@n76g2000hsh.googl egroups.com...

On Mar 13, 5:36 pm, "Stephany Young" <noone@localhostwrote:
When one uses the System.Diagnostics.Process.Start method to launch
a
common
or garden Console application, one can set the WindowStyle property
of
the
StartInfo object to ProcessWindowStyle.Hidden so that the window for
the
Console application is not visible.

However, when using some of the 'advanced' properties of the
StartInfo
object, like Username, Password and Domain, the WindowsStyle
property of
the
StartInfo object is ignored. (This is because the Process.Start
method
makes
a call to CreateProcess (or one of it's variants) intead of the
'normal'
call to ShellExecuteEx.)

Unfortunately this results in the Console application window being
shown
which looks ugly.

The effect of this can be somewhat mitigated by making the window of
the
calling application 'TopMost' for the life of the Console
application
which,
at least, makes the Console application window appear behind the
window
of
the calling application.

Has anyone who has encountered this 'issue' managed to find a way to
'hide'
the Console application window under this scenario?

This probably isn't perfect, but with your abilities you should be
able to adapt it to fit your needs.

This is the code for a form with one button named Button1 - it uses
the FindWindow and ShowWindow APIs:

Public Class Form1

Private Sub Form1_Load(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Me.Load
Process.Start("C:\ConsoleApplication1.exe")
End Sub

<System.Runtime.InteropServices.DllImport("user32" )_
Public Shared Sub ShowWindow(ByVal hWnd As IntPtr, ByVal nCmdShow
As Int32)
End Sub

<System.Runtime.InteropServices.DllImport("user32" )_
Public Shared Function FindWindow(ByVal lpClassName As String,
ByVal lpWindowname As String) As IntPtr
End Function

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles Button1.Click
Dim hWnd As IntPtr = FindWindow(Nothing, "C:
\ConsoleApplication1.exe")
ShowWindow(hWnd, 0)
End Sub

End Class

I hope this helps you out!

Thanks,

Seth Rowe

Sorry it didn't help.

Can you rewrite the console application or does the "hide" code have
to be in the calling program?

Thanks,

Seth Rowe


Mar 14 '07 #9
The StartInfo settings shown below are what I use in all cases where I want
to run and exe with an invisible console window and with the ability to read
the exe's stdout. No guarantees, but I suggest you try a couple of
experiments that do what is shown below combined with what you need to do to
run regasm. I have used this logic successfully with ipconfig.exe and
msinfo32.exe. The code is FW 1.1. Good luck.

Dim p As New Process
With p.StartInfo
.FileName = ExeFileName
.Arguments = Arguments
.UseShellExecute = False
.RedirectStandardError = True
.RedirectStandardInput = True
.RedirectStandardOutput = True
.WindowStyle = ProcessWindowStyle.Hidden
.CreateNoWindow = True
End With

Mar 14 '07 #10
On Mar 13, 4:36 pm, "Stephany Young" <noone@localhostwrote:
When one uses the System.Diagnostics.Process.Start method to launch a common
or garden Console application, one can set the WindowStyle property of the
StartInfo object to ProcessWindowStyle.Hidden so that the window for the
Console application is not visible.

However, when using some of the 'advanced' properties of the StartInfo
object, like Username, Password and Domain, the WindowsStyle property of the
StartInfo object is ignored. (This is because the Process.Start method makes
a call to CreateProcess (or one of it's variants) intead of the 'normal'
call to ShellExecuteEx.)

Unfortunately this results in the Console application window being shown
which looks ugly.

The effect of this can be somewhat mitigated by making the window of the
calling application 'TopMost' for the life of the Console application which,
at least, makes the Console application window appear behind the window of
the calling application.

Has anyone who has encountered this 'issue' managed to find a way to 'hide'
the Console application window under this scenario?
I don't know if this will help, but I have used the following class to
impersonate a user so perhaps you could use impersonation and then
call the command line app without passing the credentials to the
ProcessStartInfo object.

Chris
'*** BEGIN CODE
/// <summary>
/// Impersonate a windows logon.
/// </summary>
public class ImpersonationUtil {

/// <summary>
/// Impersonate given logon information.
/// </summary>
/// <param name="logon">Windows logon name.</param>
/// <param name="password">password</param>
/// <param name="domain">domain name</param>
/// <returns></returns>
public static bool Impersonate( string logon, string password,
string domain ) {
WindowsIdentity tempWindowsIdentity;
IntPtr token = IntPtr.Zero;
IntPtr tokenDuplicate = IntPtr.Zero;

if( LogonUser( logon, domain, password, LOGON32_LOGON_INTERACTIVE,
LOGON32_PROVIDER_DEFAULT, ref token) != 0 ) {

if ( DuplicateToken( token, 2, ref tokenDuplicate ) != 0 ) {
tempWindowsIdentity = new WindowsIdentity(tokenDuplicate);
impersonationContext = tempWindowsIdentity.Impersonate();
if ( null != impersonationContext ) return true;
}
}

return false;
}

/// <summary>
/// Unimpersonate.
/// </summary>
public static void UnImpersonate() {
impersonationContext.Undo();
}

[DllImport("advapi32.dll", CharSet=CharSet.Auto)]
public static extern int LogonUser(
string lpszUserName,
String lpszDomain,
String lpszPassword,
int dwLogonType,
int dwLogonProvider,
ref IntPtr phToken );

[DllImport("advapi32.dll",
CharSet=System.Runtime.InteropServices.CharSet.Aut o,
SetLastError=true)]
public extern static int DuplicateToken(
IntPtr hToken,
int impersonationLevel,
ref IntPtr hNewToken );

private const int LOGON32_LOGON_INTERACTIVE = 2;
private const int LOGON32_LOGON_NETWORK_CLEARTEXT = 4;
private const int LOGON32_PROVIDER_DEFAULT = 0;
private static WindowsImpersonationContext impersonationContext;
}
Mar 14 '07 #11

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

12
by: serge calderara | last post by:
Dear all, I have an application which is suppose to start another executable process. As soon as that process is running, I need to retrive its handle. The problem of the particular process I am...
1
by: Mullin Yu | last post by:
But, I want is that I can have a Main app that will start a new process or kill one particular or all process. The process will open a console exe. But, I don't want the user to close the console...
3
by: William Stacey [MVP] | last post by:
Is this a bug in fx2? I expect they did not carry forward all the StartInfo properties to api used with Username/Password. When you remove UserName/password, the window does not show as expected....
6
by: Dde | last post by:
Hi, I am having a problem starting a process from within a web service. My code works in a console program but not from the web service. Looks like the process starts, I can see it in...
1
by: BenS | last post by:
Good Morning and Happy Wednesday! I've got a web service that exposes a method that takes an string input parameter that specifies an executable on the server that starts a process. These...
1
by: Joey | last post by:
I am using the below code to run a dos based program. While it is running you can hit ctrl-c to cancel the process. Does anyone know how I can send the same keystroke to the already runing...
10
by: Stephany Young | last post by:
When one uses the System.Diagnostics.Process.Start method to launch a common or garden Console application, one can set the WindowStyle property of the StartInfo object to ProcessWindowStyle.Hidden...
3
by: =?Utf-8?B?YV93YWhvbw==?= | last post by:
I work in a group that uses a variety of third party tools to control an embedded system. I need to integrate the functionality of these tools (mostly command prompt) into a single interface. I...
0
by: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
0
by: aa123db | last post by:
Variable and constants Use var or let for variables and const fror constants. Var foo ='bar'; Let foo ='bar';const baz ='bar'; Functions function $name$ ($parameters$) { } ...
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers,...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.