Kill Process라든지 프로세스명을 지정해 일일이 짜넣는 것이 귀찮고, 무엇보다 작성자에게 룰로서 지키게 하는 것도 혹이므로, “그 로봇이 실행중에 개시한 프로세스”만”을 Kill하는 xaml 파트”를 만들어 보았다. User는, 아무것도 생각하지 않고, 그 워크플로우를 부르는 것만으로 좋은 것 같은 구조로 한다.

원래 Library 또는 Process 또는 문제

부분적인 파트로 배포하는 경우, Library로서 내용을 모르게 해도 좋지만, 이번은 User 모두에게 내용을 알고 싶기 때문에, 어디까지나 invoke 할 필요가 있는 xaml로서 배포하기로 했다(invoke도 사용 제발 원해.

기본 구조

①Assign에서 System.Diagnostics.Process.GetProcesses()로 실행중인 모든 프로세스를 얻습니다.
②OpenBrowser에서 Browser를 엽니다.
③ Try에서 실행중인 프로세스 중에서 UiPath.Executor.exe를 Process 객체로 가져옵니다.
④개시 시각(Process.StartTime 오브젝트로 사전 취득 완료)보다 전(DateTime의 비교 연산)의 것을 Kill
(↓는 Kill 할 곳까지 : Write Line의 곳)

문제와 해결

디버그 실행 중에 (여기 소중한) 문제가 발생. 처음 몇 건의 Process에는 액세스할 수 있지만, 권한의 관계상 액세스 불가능한 것이 있다. Try로 잡고 해결 (한 일로 한다).
이하, 커뮤니티에서의 제 질문과 근본적인 원인을 보여 주신 분의 해답입니다. 뭐든지
""
디버그 실행에서는 액티비티 단위로 예외를 검출하고 있으므로 Try-Catch가 보충하기 전에 예외를 보충해 버렸기 때문에 메시지가 나옵니다. 여기서 단순히 속행이라고 하면, 외부의 Try-Catch로 보충해 주고, 그대로 처리가 진행된다고 생각합니다.
""
라는 것이었습니다. 정말 발밑을 으쓱한 듯한 감각. . .
htps : // 흠 m. 우파 th. 이 m/t/우이파 th-에에 하면 r-에에-k l/176831/9? 우 = 하구 루마

곧 사내에 배포하자! 해보자. 할까. . . 확실히 한다. . . .