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