The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,512 other followers

.NET/C#: obtaining the full path of the process without the “.vshost” part.

Posted by jpluimers on 2013/10/08

When debugging from Visual Studio, the actual process is often the .vshost.exe one.

Visual Studio 2005 and up use to the .vshost.exe to expedite the debugging sequence startup, and enables some debugger and design-time features. This is also the reason why your bin directory is locked as soon as you open a project in Visual Studio.

You can disable this feature, but then starting the debugging sequence gets a lot slower, and you loose some security and design-time expression evaluation.

Often (for instance when your process needs to start itself multiple times) you want to have the name without the .vshost part.

There are also circumstances, where the encompassing process is not a .NET one but a native process (for instance when running under IIS, or when running an Office Add-In).

So I wrote an AssemblyHelper class that retrieves some key properties of the currently running process, be it a .NET assembly or a native process.

Part of the code was inspired by the original Delphi .NET (not Prism) run-time library.

A few notes:

vshost.exe basically contains the below code in the Microsoft.VisualStudio.HostingProcess namespace, which you can use to check if your code is being called from the immediate window.

namespace Microsoft.VisualStudio.HostingProcess
{
    public sealed class EntryPoint
    {
        // Methods
        private EntryPoint()
        {
        }

        [DebuggerNonUserCode]
        public static void Main()
        {
            if (Synchronize.HostingProcessInitialized != null)
            {
                Synchronize.HostingProcessInitialized.Set();
                if (Synchronize.StartRunningUsersAssembly != null)
                {
                    Synchronize.StartRunningUsersAssembly.WaitOne();
                }
            }
        }
    }
}

Some interesting reads that helped me getting this code to work:

–jeroen

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

 
%d bloggers like this: