获取应用程序启动的来源 [英] Getting the source of an application's startup

问题描述

我正在用C＃开发一个WPF应用程序，它从一个非常简单的'启动程序'exe开始，它启动主应用程序以及所有支持服务和文件系统观察程序作为单独的exe。如果没有大部分服务，主应用程序就无法运行，所以如果可以的话，我想知道主应用程序启动的来源。有什么方法可以判断主应用程序exe是从Windows资源管理器（或任何其他源）作为独立文件启动还是从'启动程序'进程启动（我将使用Process.Start（）） ;）例如，如果进程是从其exe文件启动的，那么我将显示一条消息，告诉用户他们必须使用启动器来启动它。或者我只需要检测相关服务是否正在运行并使用它？谢谢

I am developing a WPF application in C# and it starts from a very simple 'launcher' exe that starts the main application along with all of the support services and filesystem watchers as separate exe's. The main application cannot function without most of its services so I want to know the source of the startup of just the main application if it can be done. Is there any way that I can tell if the main application exe was started from windows explorer (or any other source) as a stand alone file or if it was started from the 'launcher' process (I will be using Process.Start();) For example, if the process was started from its exe file then I will display a message telling the user that they must use the launcher to start it. Or will I just have to detect if the relevant services are running and use that? Thank you

推荐答案

原则上，您可以使用P / Invoke获取有关父进程的信息（如launcher.exe）（例如，参见 HTTP：//spradip.wordpress .com / 2008/10/24 / getting-parent-process-id-from-child-without-passing-any-arguments-2 / [ ^ ]）或以管理的方式（例如，参见 http： //stackoverflow.com/questions/394816/how-to-get-parent-process-in-net-in-managed-way [ ^ ]）。



但它可以给你什么？您仍然需要告诉当前父进程可能的父进程中的哪一个，并且为此，您需要将一些标识信息（例如PID）传递给子进程（应用程序），这反过来，需要一些IPC机制。即使您将问题简化为比较父进程名称（如果您有PID，也可以使用 System.Diagnostics.Process.GetProcesses（）遍历所有当前进程，并且然后通过已知的PID找到名称，这不是一个脏方法，因为有一些机会有一些不相关的进程具有相同的名称;并且，一般来说，在应用程序中有任何硬编码的名称是脏编程。



所以，它甚至值得打扰？我不这么认为。如果您已经必须通过IPC将一些信息传递给子进程，那么直接在其环境中提供此进程信息会更好。



您真的需要修改这个launcher.exe（或其他任何东西），告诉子进程有关运行时环境的信息（无论它是什么）。在最简单的变体中，您可以在应用程序中定义命令行参数，告诉它有关环境的信息。还有许多其他方法可以传递一些数据。请参阅：

http://en.wikipedia.org/wiki/Inter-process_communication [ ^ ]。



最后，如果您需要最大的灵活性或托管您的应用程序的高级功能，您可以拥有自定义CLR主机。请从这里开始：

http：// msdn.microsoft.com/en-us/library/dd380850%28v=vs.110%29.aspx [ ^ ]。

- SA

In principle, you get information on the parent process (like "launcher.exe"), using P/Invoke (see, for example, http://spradip.wordpress.com/2008/10/24/getting-parent-process-id-from-child-without-passing-any-arguments-2/[^]) or in a managed way (see, for example, http://stackoverflow.com/questions/394816/how-to-get-parent-process-in-net-in-managed-way[^]).

But what can it give you? You still need to tell which of the possible parent processes you current parent is, and, for this purpose, you would need to pass some identification information (such as PID) to the child process (application), and this will, in turn, require some IPC mechanism. Even if you reduce the problem to comparison of the parent process name (if you have the PID, you can traverse all current process using System.Diagnostics.Process.GetProcesses() and find then name by known PID), this would not be a dirty method, because there is some chance of having some unrelated process with the same name; and, in general, having any hard-coded names in the application is dirty programming.

So, does it even worth bothering? I don't think so. If you already have to pass some information to the child process via IPC, it would be much better to directly give this process information on its environment.

You really need to modify this "launcher.exe" (or whatever it is), to tell the child process information on the runtime environment (whatever it is). In the simplest variant, you can define a command-line parameter in your application which tells it something about the environment. There are many other ways to pass some data. Please see:
http://en.wikipedia.org/wiki/Inter-process_communication[^].

And, finally, if, by any chance, you need maximum flexibility or advanced featured of hosting of your application, you can have a custom CLR host. Please start here:
http://msdn.microsoft.com/en-us/library/dd380850%28v=vs.110%29.aspx[^].

—SA

除了解决方案1之外，我有一个完全不同的想法，可能会好得多。



你看，许多学生都被教导使用防御编程风格，但在很多情况下，很多情况下这都是一个坏主意。在现代高科技编程中，攻击性编程应该占主导地位，特别是当结构异常处理或交易等技术变得司空见惯时。



这个想法是：你提到你的应用程序，当从像launcher.exe这样的父进程启动时，会使用一些支持服务。也许使用没有这些支持服务的应用程序是没有意义的，但是，即使不是这种情况，这也不应该是一个限制。您应该在应用程序运行时的最开始尝试无条件地使用这些支持服务之一（尝试连接到服务或类似的东西），在try-catch块下执行它，并且在案例中合法地失败该支持服务尚未启动。如果发生故障，应用程序捕获适当的异常会立即退出，或者根据您的直接从Shell启动方案继续运行，此时无法使用支持服务。



如果您考虑一下，这将是最合理的方法，同时也是最容易实施，最有效，最可靠和可维护的方法。嗯，老实说。 :-)

-SA

In addition to the solution 1, I have a completely different idea, which might be much better.

You see, many students are taught to use defensive style of programming, but in many, many cases it turns to be a bad idea. In modern high-tech programming, offensive programming should dominate, especially when technologies like structural exception handling or, say, transactions, became a commonplace.

The idea is: you mentioned that your application, when started from the parent process like "launcher.exe", uses some "support services". Perhaps using the application without those support services does not makes sense, but, even this is not the case, this should not be a limitation. You should simply try to unconditionally use one of these "support services" in the very beginning of the application runtime (try to connect to the service, or something like that), do it under the try-catch block, and legitimately fail in case that support service is not started. If the failure happens, the application catching appropriate exception either exits immediately, or continue running according to your "started directly from the Shell" scenario, when the supporting services can not be used.

If you think about it, it would be the most reasonable approach, and, at the same time, the easiest to implement and most efficient, reliable and maintainable. Well, honestly. :-)

—SA

这篇关于获取应用程序启动的来源的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！