I want to get the name of the currently running program, that is the executable name of the program. In C/C++ you get it from args[0]
.
-
Executable is EXE file (Windows Forms, WPF applications) ? A program can be a Desktop App (WinForms, WPF; and WinRT-Windows Phone?), Web Application, Wcf Service Application, Visual Studio Addin, Outlook-Word Addin, Unit Test in VS (MSTest), or, Silverlight Application. – Kiquenet Mar 27 '14 at 14:36
21 Answers
System.AppDomain.CurrentDomain.FriendlyName

- 60,273
- 18
- 132
- 202
-
74Beware of accepted answer. We've had issues with using `System.AppDomain.CurrentDomain.FriendlyName` under Click-Once deployed applications. For us, this is returning "*DefaultDomain*", and not the original exe name. – Gaspode Apr 13 '10 at 14:30
-
@Gaspode thanks for the heads up! So how did you get around this? – Steven A. Lowe May 05 '11 at 00:15
-
49We used this in the end: `string file = object_of_type_in_application_assembly.GetType().Assembly.Location; string app = System.IO.Path.GetFileNameWithoutExtension( file ); ` – Gaspode May 10 '11 at 15:10
-
7FriendlyName can be set to anything. Also getting the assembly location may not be enough if you have an exe with several dlls. Furthermore if you use several AppDomain, Assembly.GetCallingAssembly() returns null. – user276648 May 16 '12 at 01:19
-
3@Gaspode : it would be easier just to say Path.GetFileNameWithoutExtension(GetType().Assembly.Location) - you don't need to specify an object of a type in the current assembly. You can use GetType of this, and then you don't even need to say "this." – vbullinger Sep 24 '12 at 19:36
-
2friendly name returned by this call gives me C:\Users\root\AppData\Roaming\myapp.vshost.exe vshost.exe part is hardly something that I wanted to get back... – Califf Feb 16 '13 at 21:01
-
@Califf: that looks like the VS debugging .exe host name; are you running a debug version, perhaps through visual studio? – Steven A. Lowe Feb 16 '13 at 21:47
-
1@Steven I would prefer to use something that returns a consistent name in both Debug and Release modes, for example if is to be used to create a data profile name for the app in user's directory. So far, the Lee Grissom's answer satisfies this requirement. Sorry I somehow missed it last time. – Califf Feb 16 '13 at 22:27
-
Not the same ProcessName, FriendlyName, ModuleName and ApplicationName (AppDomain.CurrentDomain, Process, Process.MainModule). ProcessName: vstest.executionengine.x86 ConfigurationFile: C:\TFS\Tests\bin\Debug\Tests.v4.0.dll.config MainModule.FileName: C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 11.0\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW\vstest.executionengine.x86.exe MainModule.ModuleName: vstest.executionengine.x86.exe BaseDirectory: C:\TFS\Tests\bin\Debug ApplicationBase: C:\TFS\Tests\bin\Debug FriendlyName: UnitTestAdapter: Running test ApplicationName: – Kiquenet Mar 26 '14 at 08:16
-
This property can return unexpected values. I've used it in unit test and it has "UnitTestAdapter: Running test" value (which is not valid filename) – astef Nov 21 '14 at 16:40
-
@vbullinger : true, it's just that in the case we used it the code was not in the exe but an associated assembly. – Gaspode May 14 '15 at 21:37
-
1@Gaspode, What is the issue you had with "with using System.AppDomain.CurrentDomain.FriendlyName under Click-Once deployed applications"? Thank you. – Frank Feb 17 '16 at 03:24
-
@Frank, "For us, this is returning "DefaultDomain", and not the original exe name." I'm not sure what more you want to know. – Gaspode May 08 '16 at 10:20
-
10This can be useful, but it should **not** be the accepted answer: It is vastly different from what was asked for - it will coincidentally be the same thing in *some* situations, but this is something else entirely. If you didn't write the application yourself it could very well return "I like potatoes!" or whatever else your humorous colleague wrote into this property when they built the application! – AnorZaken Jun 12 '16 at 01:52
-
1System.AppDomain.CurrentDomain.FriendlyName.Substring(0,System.AppDomain.CurrentDomain.FriendlyName.IndexOf(".")) - because I need name without extension – Sharunas Bielskis Aug 07 '17 at 11:58
-
Is it possible to have that information as a constant expression? I'd like to it in a decorator. – Tristan Aug 28 '19 at 18:21
-
1@Tristan No. It's not constant. (It has to be evaluated at run time.) – John B. Lambe Nov 01 '21 at 17:25
System.AppDomain.CurrentDomain.FriendlyName
- Returns the filename with extension (e.g. MyApp.exe).
System.Diagnostics.Process.GetCurrentProcess().ProcessName
- Returns the filename without extension (e.g. MyApp).
System.Diagnostics.Process.GetCurrentProcess().MainModule.FileName
- Returns the full path and filename (e.g. C:\Examples\Processes\MyApp.exe). You could then pass this into System.IO.Path.GetFileName()
or System.IO.Path.GetFileNameWithoutExtension()
to achieve the same results as the above.

- 9,705
- 6
- 37
- 47
-
5AppDomain can be a EXE application, Web application, Unit test application, Addin Visual Studio, and "Silverlight App"(?). Maybe interesting full solution for all cases. For example, for Unit Test VS2012 - ProcessName: vstest.executionengine.x86 MainModule.FileName: C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 11.0\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW\vstest.executionengine.x86.exe MainModule.ModuleName: vstest.executionengine.x86.exe FriendlyName: UnitTestAdapter: Running test ApplicationName: – Kiquenet Mar 26 '14 at 08:18
-
A "program" can be a Desktop App (WinForms, WPF; and WinRT-Windows Phone?), Web Application, Wcf Service Application, Visual Studio Addin, Outlook-Word Addin, Unit Test in VS (MSTest), or, Silverlight Application. For example, how get service Host assembly for a Wcf Service Application hosted in IIS, not IISExpress or WebDevServer ? – Kiquenet Mar 27 '14 at 14:37
-
6+1 I’m going to go with this answer because it provides all three variations that you might need in a clean and simple way. Using the bare program name without path or extension is very useful for in-program help text (`/?` switch), because using the extension and path just clutter it unnecessarily. – Synetech Jul 06 '14 at 19:20
-
3
-
`Process.GetCurrentProcess().ProcessName()` returns *MyApp.vshost* for me. – Jonathan Wood Sep 28 '18 at 15:14
-
1Under Mono on Linux, `Process.GetCurrentProcess().MainModule.FileName` returned `/usr/bin/mono-sgen`. The `GetType().Assembly.Location` approach returned the desired executable path for both Linux and Windows. – fadden Oct 01 '18 at 17:20
-
With Mono runtime at least "System.Diagnostics.Process.GetCurrentProcess().MainModule.FileName" works but "System.AppDomain.CurrentDomain.FriendlyName" does not FYI. – zezba9000 Oct 27 '21 at 07:35
This should suffice:
Environment.GetCommandLineArgs()[0];

- 8,183
- 4
- 33
- 40
-
3Hmm, this returns (when run from vs.net and using the debug hosting thing), the location and name of the filename.vshost.exe ... that is indeed the file that is executing at this time ) – Frederik Gheysels Mar 05 '09 at 21:05
-
16This the best answer for me because `Environment.GetCommandLineArgs()` is the exact C# analogue of `argv` from C/C++. – G S Jun 03 '12 at 06:45
-
Agreed! best answer. I have a need to get Environment.GetCommandLineArgs()[1]; – OKEEngine Mar 16 '13 at 04:02
-
Works on Mono/Linux. The returned string is the full path to the exe running without the "mono " part that would be really bothersome if present. As said before this is exact analogue of C/C++ main function argv parameter. – Hatoru Hansou Jan 23 '14 at 00:02
-
5To avoid full path: `Path.GetFileNameWithoutExtension(Environment.GetCommandLineArgs()[0])` – Nathan Apr 24 '14 at 00:34
-
This won't always supply the full path, as opposed to `System.Diagnostics.Process.GetCurrentProcess().MainModule.FileName` – Ohad Schneider May 24 '14 at 17:28
-
If you copy the executable and run the two copies with different names, this returns only the most recently started executable in the AppDomain. Process.GetCurrentProcess().MainModule.FileName does not have this static problem, – Valid Sep 15 '15 at 16:02
-
If the exe is started without ".exe" (e.g. from command line), this solution will give the executable name without ".exe". – Thomas Weller Sep 17 '17 at 19:43
-
2This works well when trying to track down WCF services. The process name comes back with iisexpress in my case. But this command gives me the actual WCF service assembly name. – P.Brian.Mackey Mar 01 '18 at 16:53
System.Diagnostics.Process.GetCurrentProcess()
gets the currently running process. You can use the ProcessName
property to figure out the name. Below is a sample console app.
using System;
using System.Diagnostics;
class Program
{
static void Main(string[] args)
{
Console.WriteLine(Process.GetCurrentProcess().ProcessName);
Console.ReadLine();
}
}

- 26,356
- 27
- 122
- 180

- 9,563
- 6
- 45
- 58
-
40
-
Process.GetCurrentProcess().MainModule.FileName works perfectly from within an Excel Addin (ExcelDNA) – earcam Mar 15 '12 at 10:24
-
11This approach will fail when used on the Mono runtime; the process name for applications running on Mono will always be some variant of `.../bin/mono` on *nixes or `.../mono.exe` on Windows. – cdhowie Oct 21 '12 at 20:11
-
1This should be the accepted answer. Current AppDomain name may have nothing to do with executable process name, especially when multiple app domains are present – Ivan Krivyakov Aug 12 '15 at 19:47
-
This method can be substantially slower than playing with the Assembly class. – Erwin Mayer Jan 20 '16 at 05:33
-
@cdhowie, Could you recover the entire process invocation string such as :"/usr/bin/mono/mono /home/richard/test/foo.exe" ? Thank you. – Frank Feb 17 '16 at 03:27
-
1@Frank Perhaps using OS-specific tricks, such as reading `/proc/self/cmdline`. (`var args = File.ReadAllText("/proc/self/cmdline").Split('\0'); args = args.Take(args.Length - 1).ToArray();` would give you an array of such arguments.) – cdhowie Feb 17 '16 at 06:10
-
@Frank `Environment.CommandLine` *should* be the invocation string. Could be that mono filters itself out from it - or not - I haven't tested it on a linux machine myself so you would have to test it yourself. (I think it *does* filter away the mono-part since some applications could have behavior that depends on this property - and they probably wont be expecting it to be prefixed by mono "stuff".) – AnorZaken Jun 12 '16 at 01:35
-
Fails in .NET Core - "dotnet.exe" - (as well as Mono, for the same / similar reason). – user2864740 Jul 08 '20 at 01:53
This is the code which worked for me:
string fullName = Assembly.GetEntryAssembly().Location;
string myName = Path.GetFileNameWithoutExtension(fullName);
All the examples above gave me the processName with vshost or the running dll name.

- 2,735
- 3
- 21
- 17
-
5For those that dont know, or missed it in other answers, the namespace for Assembly is System.Reflection, and the namespace for Path is System.IO. – amalgamate Apr 02 '15 at 14:19
-
5GetEntryAssembly will return null if the application entry point is in native code rather than an assembly. – Matt Tsōnto Jul 04 '15 at 23:34
-
2
Try this:
System.Reflection.Assembly.GetExecutingAssembly()
This returns you a System.Reflection.Assembly
instance that has all the data you could ever want to know about the current application. I think that the Location
property might get what you are after specifically.

- 20,270
- 7
- 50
- 76

- 344,730
- 71
- 640
- 635
-
7It might be safer to use `CodeBase` instead of `Location` in case .NET's shadow copy feature is active. See http://blogs.msdn.com/suzcook/archive/2003/06/26/assembly-codebase-vs-assembly-location.aspx – Dirk Vollmar Aug 12 '09 at 09:28
-
23Beware of GetExecutingAssembly(): if you call this from a library assembly, it returns the name of the library assembly, which is different from the name of the entry assembly (i.e. the original executable). If you use GetEntryAssembly(), it returns the name of the actual executable, but it throws an exception if the process is running under WCF (admittedly a rare situation). For the most robust code, use Process.GetCurrentProcess().ProcessName. – Contango Nov 03 '10 at 12:01
-
@Gravitas: Certainly not, any executable that is running "interpreted", e.g. with /usr/bin/mono will have the wrong process name. Also ProcessName won't work with windows services. If you use it in a library, use GetCallingAssembly. – Stefan Steiger Mar 06 '13 at 20:15
-
2Worked for me. The property Name of the returned Assembly instance GetName() call is what you need, and does not include the ".exe" part. Also tested on Mono/Linux with expected result. Assembly.GetName().Name – Hatoru Hansou Jan 22 '14 at 23:54
-
1Hmm, note that the returned string won't change even if you rename the executable file by hand using the file explorer. While Environment.GetCommandLineArgs()[0] changes along with the actual executable filename (of course). Coincidentally, the second method resulted better for my specific situation as I want the data folder to be named as the actual executable filename. – Hatoru Hansou Jan 23 '14 at 02:25
Why nobody suggested this, its simple.
Path.GetFileName(Application.ExecutablePath)

- 1,947
- 2
- 25
- 47
-
3
-
9
-
@NineBerry You might be interested in `Application.ExecutablePath`'s [source code](http://referencesource.microsoft.com/#System.Windows.Forms/winforms/Managed/System/WinForms/Application.cs,351). – Spooky Jan 21 '16 at 23:03
-
@NineBerry See my post. This works within Console apps if you add a reference to System.Windows.Forms. – John Jul 15 '17 at 00:13
System.Reflection.Assembly.GetExecutingAssembly().ManifestModule.Name;
will give you FileName of your app like; "MyApplication.exe"

- 47,454
- 15
- 134
- 158
Couple more options:
System.Reflection.Assembly.GetExecutingAssembly().GetName().Name
Path.GetFileName(System.Reflection.Assembly.GetExecutingAssembly().GetName().CodeBase

- 18,046
- 16
- 98
- 110
-
see https://stackoverflow.com/questions/616584/how-do-i-get-the-name-of-the-current-executable-in-c#comment4394906_616588 – knocte Apr 22 '17 at 07:38
If you need the Program name to set up a firewall rule, use:
System.Diagnostics.Process.GetCurrentProcess().MainModule.FileName
This will ensure that the name is correct both when debugging in VisualStudio and when running the app directly in windows.

- 2,493
- 3
- 25
- 30

- 143
- 1
- 7
-
2For my purposes (creating a logging filename), this is the best answer. If running a hosted process (say, a service, or a web application), System.AppDomain.CurrentDomain.FriendlyName can return an ugly GUID-y name with embedded slashes. – Curt Aug 08 '16 at 17:59
-
This does *not* work for .NET Core 2+, which will report "dotnet.exe" - or perhaps the apphost if setup as such. – user2864740 Jul 08 '20 at 01:52
When uncertain or in doubt, run in circles, scream and shout.
class Ourself
{
public static string OurFileName() {
System.Reflection.Assembly _objParentAssembly;
if (System.Reflection.Assembly.GetEntryAssembly() == null)
_objParentAssembly = System.Reflection.Assembly.GetCallingAssembly();
else
_objParentAssembly = System.Reflection.Assembly.GetEntryAssembly();
if (_objParentAssembly.CodeBase.StartsWith("http://"))
throw new System.IO.IOException("Deployed from URL");
if (System.IO.File.Exists(_objParentAssembly.Location))
return _objParentAssembly.Location;
if (System.IO.File.Exists(System.AppDomain.CurrentDomain.BaseDirectory + System.AppDomain.CurrentDomain.FriendlyName))
return System.AppDomain.CurrentDomain.BaseDirectory + System.AppDomain.CurrentDomain.FriendlyName;
if (System.IO.File.Exists(System.Reflection.Assembly.GetExecutingAssembly().Location))
return System.Reflection.Assembly.GetExecutingAssembly().Location;
throw new System.IO.IOException("Assembly not found");
}
}
I can't claim to have tested each option, but it doesn't do anything stupid like returning the vhost during debugging sessions.

- 13,235
- 3
- 69
- 45
-
3+1 for amusement. :-) I would hardly use this code, though, unless I'm writing a really generic library that has no idea about its environment (and then it probably wouldn't be a good idea to maintain whatever global state you were going to use the name for). – Andrey Tarantsov Mar 22 '13 at 08:57
-
@Orwellophile A "program" can be a Desktop App (WinForms, WPF; and WinRT-Windows Phone?), Web Application, Wcf Service Application, Visual Studio Addin, Outlook-Word Addin, Unit Test in VS (MSTest), or, Silverlight Application. For example, how get service Host assembly for a Wcf Service Application hosted in IIS, not IISExpress or WebDevServer ? Any full code valid for A WinForms, WPF, Web Application, Wcf Service Application, Visual Studio Addin, Outlook-Word Addin, Unit Test in VS (MSTest) applications ? – Kiquenet Mar 27 '14 at 14:39
System.Reflection.Assembly.GetEntryAssembly().Location
returns location of exe name if assembly is not loaded from memory.System.Reflection.Assembly.GetEntryAssembly().CodeBase
returns location as URL.

- 1,270
- 12
- 16
-
Tested, this works 100%, even if its called from within a C# library. – Contango Nov 03 '10 at 10:58
-
1GetEntryAssembly() returns null if you're not in the main AppDomain. – user276648 May 16 '12 at 01:20
IF you are looking for the full path information of your executable, the reliable way to do it is to use the following:
var executable = System.Diagnostics.Process.GetCurrentProcess().MainModule
.FileName.Replace(".vshost", "");
This eliminates any issues with intermediary dlls, vshost, etc.

- 15,456
- 7
- 58
- 90
-
I tried your reliable way in Ubuntu Linux 15.10 C++ using realpath followed by STL C++ string replace and it caused Point and Click to fail. Could that have been caused by a bug in mono as our director of software surmised today? Thanks. – Frank Feb 17 '16 at 03:35
-
-
Gasponde wrote above that "We've had issues with using System.AppDomain.CurrentDomain.FriendlyName under Click-Once deployed applications." Could you make a guess as to what the issues might be with Click-Once deployed applications in .NET? Thanks. – Frank Feb 17 '16 at 05:42
-
1Returns C:\Program Files\dotnet\dotnet.exe for my Sample program in VS2017. – jwdonahue Sep 02 '19 at 21:23
You can use Environment.GetCommandLineArgs()
to obtain the arguments and Environment.CommandLine
to obtain the actual command line as entered.
Also, you can use Assembly.GetEntryAssembly()
or Process.GetCurrentProcess()
.
However, when debugging, you should be careful as this final example may give your debugger's executable name (depending on how you attach the debugger) rather than your executable, as may the other examples.

- 61,417
- 20
- 137
- 189
-
4Beware of GetExecutingAssembly(): if you call this from a library assembly, it returns the name of the library assembly, which is different from the name of the entry assembly (i.e. the original executable). If you use GetEntryAssembly(), it returns the name of the actual executable, but it throws an exception if the process is running under WCF (admittedly a rare situation). For the most robust code, use Process.GetCurrentProcess().ProcessName. – Contango Nov 03 '10 at 12:02
-
@Gravitas: good point - wow, it's been a while since I wrote this! :D I'll edit accordingly – Jeff Yates Nov 03 '10 at 14:17
-
`Environment.CommandLine` gives the absolute path, not the entered command line, at least on Mono/Linux. – Mechanical snail Dec 09 '12 at 00:14
-
@Mechanicalsnail: Sounds like Mono doesn't quite follow the documentation. Interesting. – Jeff Yates Dec 10 '12 at 15:29
If you are publishing a single file application in .NET 6.0 or above, you can use Environment.ProcessPath
Super easy, here:
Environment.CurrentDirectory + "\\" + Process.GetCurrentProcess().ProcessName

- 9,564
- 146
- 81
- 122

- 19
- 1
-
1For .NET Core Process.GetCurrentProcess().ProcessName returns "dotnet". – Evgeni Nabokov Aug 29 '18 at 23:40
-
1The current directory is temporally transient and cannot be relied on to be the location of the assembly/executable. – jwdonahue Sep 02 '19 at 20:48
On .Net Core (or Mono), most of the answers won't apply when the binary defining the process is the runtime binary of Mono or .Net Core (dotnet) and not your actual application you're interested in. In that case, use this:
var myName = Path.GetFileNameWithoutExtension(System.Reflection.Assembly.GetEntryAssembly().Location);

- 1,551
- 1
- 10
- 16
For windows apps (forms and console) I use this:
Add a reference to System.Windows.Forms in VS then:
using System.Windows.Forms;
namespace whatever
{
class Program
{
static string ApplicationName = Application.ProductName.ToString();
static void Main(string[] args)
{
........
}
}
}
This works correctly for me whether I am running the actual executable or debugging within VS.
Note that it returns the application name without the extension.
John

- 819
- 1
- 9
- 20
Is this what you want:
Assembly.GetExecutingAssembly ().Location

- 56,135
- 11
- 101
- 154
-
4Beware of GetExecutingAssembly(): if you call this from a library assembly, it returns the name of the library assembly, which is different from the name of the entry assembly (i.e. the original executable). If you use GetEntryAssembly(), it returns the name of the actual executable, but it throws an exception if the process is running under WCF (admittedly a rare situation). For the most robust code, use Process.GetCurrentProcess().ProcessName. – Contango Nov 03 '10 at 12:02
-
To get the path and the name
System.Diagnostics.Process.GetCurrentProcess().MainModule.FileName

- 17
- 1
- 7
-
This duplicates [this answer](https://stackoverflow.com/a/5120157/150605) and [this answer](https://stackoverflow.com/a/36944210/150605). – Lance U. Matthews Feb 08 '20 at 22:52