What Is the Purpose of the VShost.Exe File

What is the purpose of the vshost.exe file?

The vshost.exe feature was introduced with Visual Studio 2005 (to answer your comment).

The purpose of it is mostly to make debugging launch quicker - basically there's already a process with the framework running, just ready to load your application as soon as you want it to.

See this MSDN article and this blog post for more information.

vhost.exe. Why is that needed?

The hosting process is a feature in Visual Studio that improves
debugging performance, enables partial trust debugging, and enables
design time expression evaluation. The hosting process files contain
vshost in the file name and are placed in the output folder of your
project.

Hosting Process (vshost.exe)

What is the *.vshost.exe.config file?

Here's a blog post that talks about the vshost process and its purpose.

http://blogs.msdn.com/dtemp/archive/2004/08/17/215764.aspx

Disabling the *.vshost.exe and miscellaneous files from being created on build

Switch to the Release configuration. Then Project + Properties, Debug tab, untick the "Enable the Visual Studio hosting process" option. Build + Clean, you can delete anything that's left and it won't come back. That this option is turned on by default for the Release build is, arguably, a bit of a flaw but defensible.

The hosting process is a custom hosted version of the CLR. Exactly what it does is not well documented but it is related to configuring the security settings of the primary AppDomain. I've never heard anybody complain about battling CAS problems without it, but then it is unusual to turn it off and your app almost always runs in full trust when debugging from the IDE. It would matter if you build to a network share on early versions of .NET. The only thing that's obvious from disabling it is that anything you write with Console.Write in a gui style app will no longer appear in the Output window. It has nothing to do with speed as claimed in the highly upvoted answer in the link, the core framework DLLs are already resident in RAM since VS and MSBuild uses them.

Best thing to do is just not worry about it too much. A Setup and Deployment project will ignore it.

Should I clean *.vshost.exe and *.vshost.exe.config from release directories?

They should not be in production deployment folders in the first place.
They should only be run by Visual Studio (from the development folders).
How did they get deployed anyway?

They set up a partial trust environment for debugging. See here for more about what they do. I don't see any big danger in them staying in the deployment folders.

---

Related Topics