If you’re developing a partial trust ClickOnce application and are looking for its process in Task Manager or Process Explorer, you might be surprised that you can’t find it listed anywhere. What you will see however is a process named AppLaunch.exe. AppLaunch is a small shim tool who’s entire purpose in life is to turn around and invoke a ClickOnce application. The trick here is that it doesn’t invoke the application by executing its .exe. Rather, it acts as a simple CLR host, and uses the hosting APIs to transfer control to the application’s Main method. (This is one of the reasons that ClickOnce requires the application entry point be a managed assembly).
So why all the fancy redirection? It turns out that when you tell Windows to start a process, lots of things happen under the covers before the process actually gets started up. For instance, the application might be registered to use an AppCompat shim. Or it might have a registered debugger. Or there could be a .local file, which affects loading behavior. Any of these things (or plenty of others) could be controlled by the name of the application’s entry point. So, to work around these issues we don’t allow partially trusted applications to control the name of their entry point. Instead, they all have a main module named AppLaunch.
Since AppLaunch really just helps to protect against partial trust applications abusing something in the load path, it isn’t used to launch a FullTrust ClickOnce application. Those will show up in a process list as you would expect.
As a side effect of this, if your partial trust application happens to throw an unhandled exception, it will propagate up as an unhandled AppLaunch exception since to Windows, it looks as though AppLaunch is the entry point. When you see one of these errors, it’s worth attaching a debugger to the AppLaunch process and obtaining a stack trace of the exception to determine if it is a real bug in AppLaunch or if it’s simply a bug in the program being run.