Re: Process.Start() on Terminal Server.

Dean Cleaver <[email protected]> Sat, 21 Nov 2009 08:50:55 +1300
Newsgroups gmane.comp.windows.devel.dotnet.advanced
Message-ID <8E588B65FD82DF448592A3219102C3957E524E219E@SXSLAKL001.xceptionsoftware.com>
Ok - the reason I asked is that it used a mutex to specifically limit you t=
o only launching one instance of the app.

Dino

-----Original Message-----
From: Discussion of advanced .NET topics. [mailto:[email protected]=
E.LSOFT.COM] On Behalf Of Phil Sayers
Sent: Saturday, 21 November 2009 2:38 a.m.
To: [email protected]
Subject: Re: [ADVANCED-DOTNET] Process.Start() on Terminal Server.

No,
Not using appupdater, or the updater block from patterns and practices.


-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:[email protected]] On Behalf Of Dean Cleaver
Sent: Thursday, November 19, 2009 5:04 PM
To: [email protected]
Subject: Re: [ADVANCED-DOTNET] Process.Start() on Terminal Server.

Phil,

This isn't using the AppUpdater code from MS or a derivative is it?

Dino

-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:[email protected]] On Behalf Of Phil Sayers
Sent: Friday, 20 November 2009 7:43 a.m.
To: [email protected]
Subject: [ADVANCED-DOTNET] Process.Start() on Terminal Server.

We have a line of business, Winforms client/server application.

.Net 3.5 SP1.

=20

One of our customers is a heavy terminal services user.  We've found that a=
s soon as 1 person has started our application on the terminal server, no o=
ne else can start it up.

=20

I think the same problem is described here (not my ee post):

http://www.experts-exchange.com/Programming/Languages/C_Sharp/Q_24726101.ht=
m
l

But the "accepted solution" isn't really a solution.

=20

Our application is launched with  small stub on the end user machine (insta=
lled via elevated MSI per-machine into "program files"), and we use file co=
py &  process.start() fairly liberally so that the stub will download any u=
pdates to itself, and restart itself with the most current version before c=
ontinuing to download the real application and then finally launch that wit=
h process.Start.

=20

I'm wondering if our liberal usage of process.start() is killing us.

=20

Our code for Process.Start usage is..

=20

'copy stub to a user specific temp folder and restart.

Dim Mydir As New DirectoryInfo(My.Application.Info.DirectoryPath)

Dim tempDir As New DirectoryInfo(Path.Combine(New IO.DirectoryInfo(Applicat=
ion.LocalUserAppDataPath).Parent.FullName, "temp"))

Dim thisExecFile As New FileInfo(New
Uri(Assembly.GetExecutingAssembly.CodeBase).LocalPath)

=20

Dim newExePath As String =3D String.Empty

newExePath =3D Path.Combine(tempDir.FullName, thisExecFile.Name)

Process.Start(newExePath, "arguments")

Application.Exit()

=20

(there's a different code path for when the stub is started with args passe=
d in, but I don't think that is part of the problem at the moment)

=20

Is anyone aware of issues and workarounds with process.start and terminal s=
ervices?

=20

Thanks

Phil

=20


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
View archives and manage your subscription(s) at http://peach.ease.lsoft.co=
m/archives

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
View archives and manage your subscription(s) at http://peach.ease.lsoft.co=
m/archives

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
View archives and manage your subscription(s) at http://peach.ease.lsoft.co=
m/archives

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives