Re: Process.Start() on Terminal Server.

Ah.. nice idea.. but already accommodated, no cigar for you!

We do use a mutex but it is prefixed with "Local\" to support terminal
services.

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

Ok - the reason I asked is that it used a mutex to specifically limit you to
only launching one instance of the app.

Dino

-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:[email protected]] 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.

 

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

 

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

http://www.experts-exchange.com/Programming/Languages/C_Sharp/Q_24726101.htm
l

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

 

Our application is launched with  small stub on the end user machine
(installed via elevated MSI per-machine into "program files"), and we use
file copy &  process.start() fairly liberally so that the stub will download
any updates to itself, and restart itself with the most current version
before continuing to download the real application and then finally launch
that with process.Start.

 

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

 

Our code for Process.Start usage is..

 

'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(Application.LocalUserAppDataPath).Parent.FullName, "temp"))

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

 

Dim newExePath As String = String.Empty

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

Process.Start(newExePath, "arguments")

Application.Exit()

 

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

 

Is anyone aware of issues and workarounds with process.start and terminal
services?

 

Thanks

Phil

 


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

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

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

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

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