|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Shell, executes but no GUI is displayed .NET 2.0?..NET 2.0 based Windows Service Have a timer event in the service Private WithEvents ServiceTimer As New System.Timers.Timer(30000) Private Sub Check_Updates(ByVal sender As Object, _ ByVal e As System.Timers.ElapsedEventArgs) Handles ServiceTimer.Elapsed Shell("C:\WINDOWS\SYSTEM32\NOTEPAD.EXE", AppWinStyle.MaximizedFocus, True, -1) End Sub Start the service, no errors are triggered and in 30 seconds NOTEPAD.EXE appears in Task Manager Processes tab but not in Applications tab and there is NOTHING displayed on my screen anywhere. I've tried using Diagnostic.Process approach also, same results. Also tried waitonexit, timeout values, and nothing will permit my shelled process (NOTEPAD) to show it's interface yet it appears as a running process in Task Manager? Any suggestion as to this pretty serious flaw in .NET 2.0? Someone care to duplicate this and confirm my results? Rob It's not a flaw, and it has nothing to do with .NET.
Why are you trying to run a GUI application from a service? You can probably get this to work by allowing the service to "interact with the desktop" (check the properties of the service). Show quote "Rob R. Ainscough" <roba***@pacbell.net> wrote in message news:OrFdRDYoGHA.4104@TK2MSFTNGP04.phx.gbl... > Situation: > .NET 2.0 based Windows Service > > Have a timer event in the service > > Private WithEvents ServiceTimer As New System.Timers.Timer(30000) > > Private Sub Check_Updates(ByVal sender As Object, _ > ByVal e As System.Timers.ElapsedEventArgs) > Handles ServiceTimer.Elapsed > > Shell("C:\WINDOWS\SYSTEM32\NOTEPAD.EXE", > AppWinStyle.MaximizedFocus, True, -1) > > End Sub > > Start the service, no errors are triggered and in 30 seconds NOTEPAD.EXE > appears in Task Manager Processes tab but not in Applications tab and > there is NOTHING displayed on my screen anywhere. > > I've tried using Diagnostic.Process approach also, same results. Also > tried waitonexit, timeout values, and nothing will permit my shelled > process (NOTEPAD) to show it's interface yet it appears as a running > process in Task Manager? > > Any suggestion as to this pretty serious flaw in .NET 2.0? Someone care > to duplicate this and confirm my results? > > Rob > Brendan,
It is an Automatic Update Service that I've created to update several of my applications of client PCs. The service does some checking, downloads updates, and if the user has enabled the interface it will shell the application (GUI) that will interface with the user. To be clear, this is a shelled process that shouldn't care what the source of the shell was, but apparently a Windows Service seems to prevent any shell process from have any interface/window. This needs to be a service because making the app part of the Startup is too easy for my clients/users to remove it. "What this, I don't know, lets delete it" is all too common with my user base, services are a tad more hidden and most of my users don't even know what they are nor how to even identify them. I believe Microsoft use the same approach? If not, I'd certainly appreciate some insight on what the best approach is for this situation? Regardless, thank you!! Your solution resolved it! I've spent all day working on this and it didn't occur to me that a shelled process would be restricted by the same rules that govern a service (IMHO they process should be separate entity unto itself) -- I have coded services before and know how to set the interact with desktop via the ServiceController in the project installer -- I will do that Thanks, Rob. Show quote "Brendan Green" <bgreen@nospam.nospam> wrote in message news:%236MwbdYoGHA.220@TK2MSFTNGP05.phx.gbl... > It's not a flaw, and it has nothing to do with .NET. > > Why are you trying to run a GUI application from a service? You can > probably get this to work by allowing the service to "interact with the > desktop" (check the properties of the service). > > "Rob R. Ainscough" <roba***@pacbell.net> wrote in message > news:OrFdRDYoGHA.4104@TK2MSFTNGP04.phx.gbl... >> Situation: >> .NET 2.0 based Windows Service >> >> Have a timer event in the service >> >> Private WithEvents ServiceTimer As New System.Timers.Timer(30000) >> >> Private Sub Check_Updates(ByVal sender As Object, _ >> ByVal e As System.Timers.ElapsedEventArgs) >> Handles ServiceTimer.Elapsed >> >> Shell("C:\WINDOWS\SYSTEM32\NOTEPAD.EXE", >> AppWinStyle.MaximizedFocus, True, -1) >> >> End Sub >> >> Start the service, no errors are triggered and in 30 seconds NOTEPAD.EXE >> appears in Task Manager Processes tab but not in Applications tab and >> there is NOTHING displayed on my screen anywhere. >> >> I've tried using Diagnostic.Process approach also, same results. Also >> tried waitonexit, timeout values, and nothing will permit my shelled >> process (NOTEPAD) to show it's interface yet it appears as a running >> process in Task Manager? >> >> Any suggestion as to this pretty serious flaw in .NET 2.0? Someone care >> to duplicate this and confirm my results? >> >> Rob >> > > And you may open a security hole
....http://www.microsoft.com/technet/archive/security/news/htshat.mspx?mfr=true I believe this functionality has also been removed in vista so your service would not work there.Your service will only be able to interact with a different desktop (not the one the user is on). MS has said for a long time that this was a bad way of doing things. The general way of doing this is to have a back end service and a front end client app that talks to the back end service through a mechanism such as remoting. The service then tells the client app to show something to the user this way the client app runs in the same security context as the user (as opposed to a service running under a higher priv level). Cheers, Greg Young MVP - C# http://codebetter.com/blogs/gregyoung Show quote "Rob R. Ainscough" <roba***@pacbell.net> wrote in message news:uYFAfcZoGHA.4816@TK2MSFTNGP03.phx.gbl... > Brendan, > > It is an Automatic Update Service that I've created to update several of > my applications of client PCs. The service does some checking, downloads > updates, and if the user has enabled the interface it will shell the > application (GUI) that will interface with the user. To be clear, this is > a shelled process that shouldn't care what the source of the shell was, > but apparently a Windows Service seems to prevent any shell process from > have any interface/window. > > This needs to be a service because making the app part of the Startup is > too easy for my clients/users to remove it. "What this, I don't know, > lets delete it" is all too common with my user base, services are a tad > more hidden and most of my users don't even know what they are nor how to > even identify them. > > I believe Microsoft use the same approach? If not, I'd certainly > appreciate some insight on what the best approach is for this situation? > > Regardless, thank you!! Your solution resolved it! I've spent all day > working on this and it didn't occur to me that a shelled process would be > restricted by the same rules that govern a service (IMHO they process > should be separate entity unto itself) -- I have coded services before and > know how to set the interact with desktop via the ServiceController in the > project installer -- I will do that > > Thanks, Rob. > > "Brendan Green" <bgreen@nospam.nospam> wrote in message > news:%236MwbdYoGHA.220@TK2MSFTNGP05.phx.gbl... >> It's not a flaw, and it has nothing to do with .NET. >> >> Why are you trying to run a GUI application from a service? You can >> probably get this to work by allowing the service to "interact with the >> desktop" (check the properties of the service). >> >> "Rob R. Ainscough" <roba***@pacbell.net> wrote in message >> news:OrFdRDYoGHA.4104@TK2MSFTNGP04.phx.gbl... >>> Situation: >>> .NET 2.0 based Windows Service >>> >>> Have a timer event in the service >>> >>> Private WithEvents ServiceTimer As New System.Timers.Timer(30000) >>> >>> Private Sub Check_Updates(ByVal sender As Object, _ >>> ByVal e As System.Timers.ElapsedEventArgs) >>> Handles ServiceTimer.Elapsed >>> >>> Shell("C:\WINDOWS\SYSTEM32\NOTEPAD.EXE", >>> AppWinStyle.MaximizedFocus, True, -1) >>> >>> End Sub >>> >>> Start the service, no errors are triggered and in 30 seconds NOTEPAD.EXE >>> appears in Task Manager Processes tab but not in Applications tab and >>> there is NOTHING displayed on my screen anywhere. >>> >>> I've tried using Diagnostic.Process approach also, same results. Also >>> tried waitonexit, timeout values, and nothing will permit my shelled >>> process (NOTEPAD) to show it's interface yet it appears as a running >>> process in Task Manager? >>> >>> Any suggestion as to this pretty serious flaw in .NET 2.0? Someone care >>> to duplicate this and confirm my results? >>> >>> Rob >>> >> >> > > So your suggesting I read up and learn remoting for the next several days
for what amounts to be a very basic GUI that basically permits the user to Enable/Disable and Turn notifications on/off and view the progress of the downloads/installs? I would find it unlikely that Vista will not permit existing services that interact with the desktop to not work come the final build -- a quick check for Services that interact with my desktop comes up with a count of 12 (Symatec, hardware support services, and a few others) -- so M$ will have to come up with some solution. I would disagree that "I'm opening a security hole" -- the hole exists due to the poor implementation of the OS -- security isn't something that should get in the way of a valid process installed by a user. MS can try to pass the buck, but it ultimately stops on their door step in terms of public perception -- when you hear about the next virus on the news, you don't hear about the developer or IT person that "opened hole", no, you hear "Microsoft". So Microsoft can continue to blindly point fingers, but it doesn't change the public perception and fear of M$ operating systems and viruses. The folks at Redmond either need to come up with a better plan or seal their static fate with flat revenue and declining stock value. Remoting -- yet another "new and improved approach to be obsolete within the next 6 months as it's deemed unsecure, slow, buggy, etc. etc." Rob. Show quote "Greg Young" <druckdruckREMOVEgo***@hotmail.com> wrote in message news:OhYdxuaoGHA.4816@TK2MSFTNGP03.phx.gbl... > And you may open a security hole > ...http://www.microsoft.com/technet/archive/security/news/htshat.mspx?mfr=true > I believe this functionality has also been removed in vista so your > service would not work there.Your service will only be able to interact > with a different desktop (not the one the user is on). MS has said for a > long time that this was a bad way of doing things. > > The general way of doing this is to have a back end service and a front > end client app that talks to the back end service through a mechanism such > as remoting. The service then tells the client app to show something to > the user this way the client app runs in the same security context as the > user (as opposed to a service running under a higher priv level). > > Cheers, > > Greg Young > MVP - C# > http://codebetter.com/blogs/gregyoung > > > "Rob R. Ainscough" <roba***@pacbell.net> wrote in message > news:uYFAfcZoGHA.4816@TK2MSFTNGP03.phx.gbl... >> Brendan, >> >> It is an Automatic Update Service that I've created to update several of >> my applications of client PCs. The service does some checking, downloads >> updates, and if the user has enabled the interface it will shell the >> application (GUI) that will interface with the user. To be clear, this >> is a shelled process that shouldn't care what the source of the shell >> was, but apparently a Windows Service seems to prevent any shell process >> from have any interface/window. >> >> This needs to be a service because making the app part of the Startup is >> too easy for my clients/users to remove it. "What this, I don't know, >> lets delete it" is all too common with my user base, services are a tad >> more hidden and most of my users don't even know what they are nor how to >> even identify them. >> >> I believe Microsoft use the same approach? If not, I'd certainly >> appreciate some insight on what the best approach is for this situation? >> >> Regardless, thank you!! Your solution resolved it! I've spent all day >> working on this and it didn't occur to me that a shelled process would be >> restricted by the same rules that govern a service (IMHO they process >> should be separate entity unto itself) -- I have coded services before >> and know how to set the interact with desktop via the ServiceController >> in the project installer -- I will do that >> >> Thanks, Rob. >> >> "Brendan Green" <bgreen@nospam.nospam> wrote in message >> news:%236MwbdYoGHA.220@TK2MSFTNGP05.phx.gbl... >>> It's not a flaw, and it has nothing to do with .NET. >>> >>> Why are you trying to run a GUI application from a service? You can >>> probably get this to work by allowing the service to "interact with the >>> desktop" (check the properties of the service). >>> >>> "Rob R. Ainscough" <roba***@pacbell.net> wrote in message >>> news:OrFdRDYoGHA.4104@TK2MSFTNGP04.phx.gbl... >>>> Situation: >>>> .NET 2.0 based Windows Service >>>> >>>> Have a timer event in the service >>>> >>>> Private WithEvents ServiceTimer As New System.Timers.Timer(30000) >>>> >>>> Private Sub Check_Updates(ByVal sender As Object, _ >>>> ByVal e As System.Timers.ElapsedEventArgs) >>>> Handles ServiceTimer.Elapsed >>>> >>>> Shell("C:\WINDOWS\SYSTEM32\NOTEPAD.EXE", >>>> AppWinStyle.MaximizedFocus, True, -1) >>>> >>>> End Sub >>>> >>>> Start the service, no errors are triggered and in 30 seconds >>>> NOTEPAD.EXE appears in Task Manager Processes tab but not in >>>> Applications tab and there is NOTHING displayed on my screen anywhere. >>>> >>>> I've tried using Diagnostic.Process approach also, same results. Also >>>> tried waitonexit, timeout values, and nothing will permit my shelled >>>> process (NOTEPAD) to show it's interface yet it appears as a running >>>> process in Task Manager? >>>> >>>> Any suggestion as to this pretty serious flaw in .NET 2.0? Someone >>>> care to duplicate this and confirm my results? >>>> >>>> Rob >>>> >>> >>> >> >> > > Maybe you should port your program to Linux? Good luck rtfm'ing.
Show quote "Rob R. Ainscough" wrote: > So your suggesting I read up and learn remoting for the next several days > for what amounts to be a very basic GUI that basically permits the user to > Enable/Disable and Turn notifications on/off and view the progress of the > downloads/installs? I would find it unlikely that Vista will not permit > existing services that interact with the desktop to not work come the final > build -- a quick check for Services that interact with my desktop comes up > with a count of 12 (Symatec, hardware support services, and a few others) -- > so M$ will have to come up with some solution. > > I would disagree that "I'm opening a security hole" -- the hole exists due > to the poor implementation of the OS -- security isn't something that should > get in the way of a valid process installed by a user. MS can try to pass > the buck, but it ultimately stops on their door step in terms of public > perception -- when you hear about the next virus on the news, you don't hear > about the developer or IT person that "opened hole", no, you hear > "Microsoft". So Microsoft can continue to blindly point fingers, but it > doesn't change the public perception and fear of M$ operating systems and > viruses. The folks at Redmond either need to come up with a better plan or > seal their static fate with flat revenue and declining stock value. > > Remoting -- yet another "new and improved approach to be obsolete within the > next 6 months as it's deemed unsecure, slow, buggy, etc. etc." > > Rob. > > "Greg Young" <druckdruckREMOVEgo***@hotmail.com> wrote in message > news:OhYdxuaoGHA.4816@TK2MSFTNGP03.phx.gbl... > > And you may open a security hole > > ...http://www.microsoft.com/technet/archive/security/news/htshat.mspx?mfr=true > > I believe this functionality has also been removed in vista so your > > service would not work there.Your service will only be able to interact > > with a different desktop (not the one the user is on). MS has said for a > > long time that this was a bad way of doing things. > > > > The general way of doing this is to have a back end service and a front > > end client app that talks to the back end service through a mechanism such > > as remoting. The service then tells the client app to show something to > > the user this way the client app runs in the same security context as the > > user (as opposed to a service running under a higher priv level). > > > > Cheers, > > > > Greg Young > > MVP - C# > > http://codebetter.com/blogs/gregyoung > > > > > > "Rob R. Ainscough" <roba***@pacbell.net> wrote in message > > news:uYFAfcZoGHA.4816@TK2MSFTNGP03.phx.gbl... > >> Brendan, > >> > >> It is an Automatic Update Service that I've created to update several of > >> my applications of client PCs. The service does some checking, downloads > >> updates, and if the user has enabled the interface it will shell the > >> application (GUI) that will interface with the user. To be clear, this > >> is a shelled process that shouldn't care what the source of the shell > >> was, but apparently a Windows Service seems to prevent any shell process > >> from have any interface/window. > >> > >> This needs to be a service because making the app part of the Startup is > >> too easy for my clients/users to remove it. "What this, I don't know, > >> lets delete it" is all too common with my user base, services are a tad > >> more hidden and most of my users don't even know what they are nor how to > >> even identify them. > >> > >> I believe Microsoft use the same approach? If not, I'd certainly > >> appreciate some insight on what the best approach is for this situation? > >> > >> Regardless, thank you!! Your solution resolved it! I've spent all day > >> working on this and it didn't occur to me that a shelled process would be > >> restricted by the same rules that govern a service (IMHO they process > >> should be separate entity unto itself) -- I have coded services before > >> and know how to set the interact with desktop via the ServiceController > >> in the project installer -- I will do that > >> > >> Thanks, Rob. > >> > >> "Brendan Green" <bgreen@nospam.nospam> wrote in message > >> news:%236MwbdYoGHA.220@TK2MSFTNGP05.phx.gbl... > >>> It's not a flaw, and it has nothing to do with .NET. > >>> > >>> Why are you trying to run a GUI application from a service? You can > >>> probably get this to work by allowing the service to "interact with the > >>> desktop" (check the properties of the service). > >>> > >>> "Rob R. Ainscough" <roba***@pacbell.net> wrote in message > >>> news:OrFdRDYoGHA.4104@TK2MSFTNGP04.phx.gbl... > >>>> Situation: > >>>> .NET 2.0 based Windows Service > >>>> > >>>> Have a timer event in the service > >>>> > >>>> Private WithEvents ServiceTimer As New System.Timers.Timer(30000) > >>>> > >>>> Private Sub Check_Updates(ByVal sender As Object, _ > >>>> ByVal e As System.Timers.ElapsedEventArgs) > >>>> Handles ServiceTimer.Elapsed > >>>> > >>>> Shell("C:\WINDOWS\SYSTEM32\NOTEPAD.EXE", > >>>> AppWinStyle.MaximizedFocus, True, -1) > >>>> > >>>> End Sub > >>>> > >>>> Start the service, no errors are triggered and in 30 seconds > >>>> NOTEPAD.EXE appears in Task Manager Processes tab but not in > >>>> Applications tab and there is NOTHING displayed on my screen anywhere. > >>>> > >>>> I've tried using Diagnostic.Process approach also, same results. Also > >>>> tried waitonexit, timeout values, and nothing will permit my shelled > >>>> process (NOTEPAD) to show it's interface yet it appears as a running > >>>> process in Task Manager? > >>>> > >>>> Any suggestion as to this pretty serious flaw in .NET 2.0? Someone > >>>> care to duplicate this and confirm my results? > >>>> > >>>> Rob > >>>> > >>> > >>> > >> > >> > > > > > > > I won't harp on the interactive service I think you have been told "don't do
that" enough in the various posts you put up. I will leave you with one more link though .. note the "it doesn't actually work" paragraph http://blogs.msdn.com/larryosterman/archive/2005/09/14/466175.aspx Show quote > So your suggesting I read up and learn remoting for the next several days There is a really easy way to figure out if it is bad code/configuration or > for what amounts to be a very basic GUI that basically permits the user to > Enable/Disable and Turn notifications on/off and view the progress of the > downloads/installs? I would find it unlikely that Vista will not permit > existing services that interact with the desktop to not work come the > final build -- a quick check for Services that interact with my desktop > comes up with a count of 12 (Symatec, hardware support services, and a few > others) -- so M$ will have to come up with some solution. > I would disagree that "I'm opening a security hole" -- the hole exists due > to the poor implementation of the OS -- security isn't something that > should get in the way of a valid process installed by a user. MS can try > to pass the buck, but it ultimately stops on their door step in terms of > public perception -- when you hear about the next virus on the news, you > don't hear about the developer or IT person that "opened hole", no, you > hear "Microsoft". So Microsoft can continue to blindly point fingers, but > it doesn't change the public perception and fear of M$ operating systems > and viruses. The folks at Redmond either need to come up with a better > plan or seal their static fate with flat revenue and declining stock > value. an OS problem. If the system is secure, then you install your software and it has a gaping hole it is not the OS that caused the problem. Let's take these two quotestogether .. you rail on MS for having the problem right after you rail them for trying to change it breaking backwards compatibility (is there anything they can do right?) There is currently a very strong security movement (see SDL). As for it being an OS problem .. it is a configuration problem .. someone who doesn't know what they are doing can make even the most secure OS insecure if they have admin privileges. If default services came with windows that ran in this method (and not as a reduced privilege user) I could buy this argument but with MS having made this common knowledge years ago I have a hard time blaming them for it. The moment MS says "this configuration has problems" the problem falls to the feet of developers/admins. I hate to be the one to break it to you but if you write bad code on an os you would consider to be secure like openbsd and you take that bad code and give it escalated privs you have a vulnerability and it is not the fault of the OS. It is the fault of the developer who didn't bother to care. Not surprisingly an admin/developer with super user privs can easily make an openbsd box not secure. >security isn't something that should get in the way of a valid process I guess that installing a ftp server with a buffer overflow attack is >installed by a user. something a user might want to install as well. It is a constant trade off.between ease functionality and security .. look at the people disabling security in vista because they are used to running as admin on their machine. The fact of the matter is that not all machines need to be secure, but the software should atleast support running in a secure fashion. Cheers, Greg Show quote "Rob R. Ainscough" <roba***@pacbell.net> wrote in message news:u%23sJuGfoGHA.5104@TK2MSFTNGP04.phx.gbl... > So your suggesting I read up and learn remoting for the next several days > for what amounts to be a very basic GUI that basically permits the user to > Enable/Disable and Turn notifications on/off and view the progress of the > downloads/installs? I would find it unlikely that Vista will not permit > existing services that interact with the desktop to not work come the > final build -- a quick check for Services that interact with my desktop > comes up with a count of 12 (Symatec, hardware support services, and a few > others) -- so M$ will have to come up with some solution. > > I would disagree that "I'm opening a security hole" -- the hole exists due > to the poor implementation of the OS -- security isn't something that > should get in the way of a valid process installed by a user. MS can try > to pass the buck, but it ultimately stops on their door step in terms of > public perception -- when you hear about the next virus on the news, you > don't hear about the developer or IT person that "opened hole", no, you > hear "Microsoft". So Microsoft can continue to blindly point fingers, but > it doesn't change the public perception and fear of M$ operating systems > and viruses. The folks at Redmond either need to come up with a better > plan or seal their static fate with flat revenue and declining stock > value. > > Remoting -- yet another "new and improved approach to be obsolete within > the next 6 months as it's deemed unsecure, slow, buggy, etc. etc." > > Rob. > > "Greg Young" <druckdruckREMOVEgo***@hotmail.com> wrote in message > news:OhYdxuaoGHA.4816@TK2MSFTNGP03.phx.gbl... >> And you may open a security hole >> ...http://www.microsoft.com/technet/archive/security/news/htshat.mspx?mfr=true >> I believe this functionality has also been removed in vista so your >> service would not work there.Your service will only be able to interact >> with a different desktop (not the one the user is on). MS has said for a >> long time that this was a bad way of doing things. >> >> The general way of doing this is to have a back end service and a front >> end client app that talks to the back end service through a mechanism >> such as remoting. The service then tells the client app to show something >> to the user this way the client app runs in the same security context as >> the user (as opposed to a service running under a higher priv level). >> >> Cheers, >> >> Greg Young >> MVP - C# >> http://codebetter.com/blogs/gregyoung >> >> >> "Rob R. Ainscough" <roba***@pacbell.net> wrote in message >> news:uYFAfcZoGHA.4816@TK2MSFTNGP03.phx.gbl... >>> Brendan, >>> >>> It is an Automatic Update Service that I've created to update several of >>> my applications of client PCs. The service does some checking, >>> downloads updates, and if the user has enabled the interface it will >>> shell the application (GUI) that will interface with the user. To be >>> clear, this is a shelled process that shouldn't care what the source of >>> the shell was, but apparently a Windows Service seems to prevent any >>> shell process from have any interface/window. >>> >>> This needs to be a service because making the app part of the Startup is >>> too easy for my clients/users to remove it. "What this, I don't know, >>> lets delete it" is all too common with my user base, services are a tad >>> more hidden and most of my users don't even know what they are nor how >>> to even identify them. >>> >>> I believe Microsoft use the same approach? If not, I'd certainly >>> appreciate some insight on what the best approach is for this situation? >>> >>> Regardless, thank you!! Your solution resolved it! I've spent all day >>> working on this and it didn't occur to me that a shelled process would >>> be restricted by the same rules that govern a service (IMHO they process >>> should be separate entity unto itself) -- I have coded services before >>> and know how to set the interact with desktop via the ServiceController >>> in the project installer -- I will do that >>> >>> Thanks, Rob. >>> >>> "Brendan Green" <bgreen@nospam.nospam> wrote in message >>> news:%236MwbdYoGHA.220@TK2MSFTNGP05.phx.gbl... >>>> It's not a flaw, and it has nothing to do with .NET. >>>> >>>> Why are you trying to run a GUI application from a service? You can >>>> probably get this to work by allowing the service to "interact with the >>>> desktop" (check the properties of the service). >>>> >>>> "Rob R. Ainscough" <roba***@pacbell.net> wrote in message >>>> news:OrFdRDYoGHA.4104@TK2MSFTNGP04.phx.gbl... >>>>> Situation: >>>>> .NET 2.0 based Windows Service >>>>> >>>>> Have a timer event in the service >>>>> >>>>> Private WithEvents ServiceTimer As New System.Timers.Timer(30000) >>>>> >>>>> Private Sub Check_Updates(ByVal sender As Object, _ >>>>> ByVal e As >>>>> System.Timers.ElapsedEventArgs) Handles ServiceTimer.Elapsed >>>>> >>>>> Shell("C:\WINDOWS\SYSTEM32\NOTEPAD.EXE", >>>>> AppWinStyle.MaximizedFocus, True, -1) >>>>> >>>>> End Sub >>>>> >>>>> Start the service, no errors are triggered and in 30 seconds >>>>> NOTEPAD.EXE appears in Task Manager Processes tab but not in >>>>> Applications tab and there is NOTHING displayed on my screen anywhere. >>>>> >>>>> I've tried using Diagnostic.Process approach also, same results. Also >>>>> tried waitonexit, timeout values, and nothing will permit my shelled >>>>> process (NOTEPAD) to show it's interface yet it appears as a running >>>>> process in Task Manager? >>>>> >>>>> Any suggestion as to this pretty serious flaw in .NET 2.0? Someone >>>>> care to duplicate this and confirm my results? >>>>> >>>>> Rob >>>>> >>>> >>>> >>> >>> >> >> > >  |
|||||||||||||||||||||||
Other interesting topics