We Keep Coding

How do I get the name of the current executable in C#? (.NET 5 edition)

How do I get the name the executable was invoked as (equivalent to C's argv[0])? I actually need to handle somebody renaming the executable and stuff like that.
There's a famous question with lots of answers that don't work. Answers tried:
System.AppDomain.CurrentDomain.FriendlyName
returns the name it was compiled as
System.Diagnostics.Process.GetCurrentProcess().ProcessName
strips extension (ever rename a .exe to a .com?), also sees through symbolic links
Environment.GetCommandLineArgs()[0]
It returns a name ending in .dll, clearly an error.
Assembly.GetEntryAssembly().Location
Returns null
System.Diagnostics.Process.GetCurrentProcess().MainModule.FileName
Returns a .dll name again.
The documentation for .net 5.0 says Environment.GetCommandLineArguments()[0] works; however it doesn't actually work. It somehow sees through symbolic links and returns the real executable name.
What I'm trying to do is link all of our stuff into a single multi-call binary so I can use the .net 5 framework reducer on the resulting binary so I don't have to ship about 30MB of .net 5 framework we're not using. I really don't want to do a platform ladder and P/Invoke a bunch of stuff unless I have to.
I'm after argv[0] directly, not the running process executable name. In the case of symbolic links, these differ.

Came across this with .NET 6, where Process.GetCurrentProcess().MainModule?.FileName seems to be working fine now, and there's also Environment.ProcessPath.
If targeting Windows only, it might be safer (more predictable) to use interop. Below are some options, including the native GetModuleFileName and GetCommandLine:
using System.ComponentModel;
using System.Diagnostics;
using System.Reflection;
using System.Runtime.InteropServices;
using System.Text;
Console.WriteLine("Process.GetCurrentProcess().MainModule?.FileName");
Console.WriteLine(Process.GetCurrentProcess().MainModule?.FileName);
Console.WriteLine();
Console.WriteLine("Assembly.GetExecutingAssembly().Location");
Console.WriteLine(Assembly.GetExecutingAssembly().Location);
Console.WriteLine();
Console.WriteLine("Environment.ProcessPath");
Console.WriteLine(Environment.ProcessPath);
Console.WriteLine();
Console.WriteLine("Environment.CommandLine");
Console.WriteLine(Environment.CommandLine);
Console.WriteLine();
Console.WriteLine("Environment.GetCommandLineArgs()[0]");
Console.WriteLine(Environment.GetCommandLineArgs()[0]);
Console.WriteLine();
Console.WriteLine("Win32.GetProcessPath()");
Console.WriteLine(Win32.GetProcessPath());
Console.WriteLine();
Console.WriteLine("Win32.GetProcessCommandLine()");
Console.WriteLine(Win32.GetProcessCommandLine());
Console.WriteLine();
public static class Win32
{
private const int MAX_PATH = 260;
private const int INSUFFICIENT_BUFFER = 0x007A;
private const int MAX_UNICODESTRING_LEN = short.MaxValue;
[DllImport("kernel32.dll", CharSet = CharSet.Unicode)]
private static extern IntPtr GetCommandLine();
[DllImport("kernel32.dll", SetLastError = true, CharSet = CharSet.Unicode)]
[PreserveSig]
[return: MarshalAs(UnmanagedType.U4)]
private static extern int GetModuleFileName(
IntPtr hModule, StringBuilder lpFilename, [MarshalAs(UnmanagedType.U4)] int nSize);
public static string GetProcessCommandLine()
{
return Marshal.PtrToStringUni(GetCommandLine()) ??
throw new Win32Exception(nameof(GetCommandLine));
}
public static string GetProcessPath()
{
var buffer = new StringBuilder(MAX_PATH);
while (true)
{
int size = GetModuleFileName(IntPtr.Zero, buffer, buffer.Capacity);
if (size == 0)
{
throw new Win32Exception();
}
if (size == buffer.Capacity)
{
// double the buffer size and try again.
buffer.EnsureCapacity(buffer.Capacity * 2);
continue;
}
return Path.GetFullPath(buffer.ToString());
}
}
}
The output when running via dotnet run:
Process.GetCurrentProcess().MainModule?.FileName
C:\temp\ProcessPath\bin\Debug\net6.0\ProcessPath.exe
Assembly.GetExecutingAssembly().Location
C:\temp\ProcessPath\bin\Debug\net6.0\ProcessPath.dll
Environment.ProcessPath
C:\temp\ProcessPath\bin\Debug\net6.0\ProcessPath.exe
Environment.CommandLine
C:\temp\ProcessPath\bin\Debug\net6.0\ProcessPath.dll
Environment.GetCommandLineArgs()[0]
C:\temp\ProcessPath\bin\Debug\net6.0\ProcessPath.dll
Win32.GetProcessPath()
C:\temp\ProcessPath\bin\Debug\net6.0\ProcessPath.exe
Win32.GetProcessCommandLine()
"C:\temp\ProcessPath\bin\Debug\net6.0\ProcessPath.exe"
Oh, and for a Windows Forms application, there always has been Application.ExecutablePath.
Updated, running it on Ubuntu 22.04 with .NET 6.0.2 (with Win32 interop removed), either via dotnet run or directly as ./ProcessPath:
Process.GetCurrentProcess().MainModule?.FileName
/home/noseratio/ProcessPath/bin/Debug/net6.0/ProcessPath
Assembly.GetExecutingAssembly().Location
/home/noseratio/ProcessPath/bin/Debug/net6.0/ProcessPath.dll
Environment.ProcessPath
/home/noseratio/ProcessPath/bin/Debug/net6.0/ProcessPath
Environment.CommandLine
/home/noseratio/ProcessPath/bin/Debug/net6.0/ProcessPath.dll
Environment.GetCommandLineArgs()[0]
/home/noseratio/ProcessPath/bin/Debug/net6.0/ProcessPath.dll

After watching everything fail, it became necessary to P/Invoke stuff to make this work. While Process.GetCurrentProcess().MainModule?.FileName reliably returns the executable binary (at least when not running under the debugger), this does not provide the command invocation the binary was launched with.
On Windows, GetCommandLine() is P/Invokable and needs only some parsing to get the information. On *n?x, reading /proc/self/cmdline does the same job.
I built a library encapsulating this. https://github.com/joshudson/Emet/tree/master/MultiCall You can find binaries on nuget.org ready to go.
I should have self-answered a long time ago. Better late than never. Nobody seemed to care until now.

Using .NET Core 3.1, this worked for me to restart a currently running program.
string filename = Process.GetCurrentProcess().MainModule.FileName;
System.Diagnostics.Process.Start(filename);
// Closes the current process
Environment.Exit(0);

MsiGetProductInfo returning ERROR_UNKNOWN_PRODUCT for an installed product

I am trying to programmatically query for information from the installer project. This information is defined in the installer and I don't want to duplicate it in code. I need to get the Publisher installer property (and a few others), but can't seem to get things to work.
I am querying using:
[DllImport("msi.dll", CharSet = CharSet.Unicode)]
private static extern Int32 MsiGetProductInfo(
string product,
string property,
[Out] StringBuilder valueBuf,
ref Int32 len);
...
int length = 512;
StringBuilder builder = new StringBuilder(length);
var result = MsiGetProductInfo(
"{censored}",
"Publisher",
builder,
ref length);
Using RegEdit, I can see an uninstallable product:
{censored}_is1
And this is my application with a "Publisher" key that is what I expect. I am not sure why the "_is1" suffix is there. The installer was made using Inno Setup, maybe that is related. I have tried adding this suffix on the product code in the call to MsiGetProductInfo but it had no effect.
The call returns 1605 which is ERROR_UNKNOWN_PRODUCT.
How do I properly query for the publisher of this product?

The MSI API is only useful for MSI-based installations. Inno Setup does not create MSI packages so you can't use the MSI API to query about Inno Setup installations.

Accessing Patch Information?

Does anyone know, how given a GUID that identifies an installed product, you can find the patches installed for that product with C#?
The application is quite complex and from time to time, we create patches (MSP files) through Orca/MSI. These patches can then be installed on the customer's computer and can then be viewed in "View Installed Updates" under Programs and Features.
I've tried two approaches:
Using WMI I can find my product in Win32_Product and retrieve the
information there. However, if I then query either
Win32_PatchPackage or Win32_Patch for matches against the
"ProductCode". I would have expected the captions/description to
contain the information I want, but all I get is another separate
set of GUIDs for each which doesn't seem very obvious what to do
with it.
Similarly, using the Registry I can find the Product (under
HKLM\Software\Microsoft\Uninstall\\, and with some digging I
can find Patches (under
HKLM\Software\Microsoft\Installer\UserData\S-1-5-18\Products\)
but the key isn't obvious. It isn't the same as my products
installer GUID.
This question discusses similar issues, but the questioner was looking for the Windows patches, while I need my own applicaitons patches - so there solution doesn't really work for me.
Thanks in advance.

I was able to achieve this by plugging the ProductCode returned from Win32_PatchPackage into a Win32 dll and then using as so.
[DllImport("msi.dll", CharSet = CharSet.Unicode)]
internal static extern Int32 MsiGetPatchInfoEx(string szPatchCode, string szProductCode, string szUserSid, int dwContext, string szProperty, [Out] StringBuilder lpValue, ref Int32 pcchValue);
// See http://msdn.microsoft.com/en-us/library/windows/desktop/aa370128%28v=vs.85%29.aspx
// for valid values for the property paramater
private static string getPatchInfoProperty(string patchCode, string productCode, string property)
{
StringBuilder output = new StringBuilder(512);
int len = 512;
MsiGetPatchInfoEx(patchCode, productCode, null, 4, property, output, ref len);
return output.ToString();
}
public static string GetPatchDisplayName(string patchCode, string productCode)
{
return getPatchInfoProperty(patchCode, productCode, "DisplayName");
}

How to get the Windows 7 theme name

Windows 7 comes with several built-in themes. They can be accessed by right-clicking the desktop and choosing Personalize. Under Personalize, there is a section names "Aero Themes" containing themes like "Architecture" "Nature" and so on.
I tried using uxtheme.dll's GetCurrentThemeName, but it's actually giving the style name:
"C:\Windows\resources\Themes\Aero\Aero.msstyles" unless my current theme is set to Windows Basic, in which case it returns an empty string. Is there an API that actually returns the theme name, like "Nature" "Architecture" etc...?
The code I tried is as follows:
[DllImport("uxtheme", ExactSpelling = true, CharSet = CharSet.Unicode)]
public extern static Int32 GetCurrentThemeName(StringBuilder stringThemeName,
int lengthThemeName, StringBuilder stringColorName, int lengthColorName,
StringBuilder stringSizeName, int lengthSizeName);
StringBuilder stringThemeName = new StringBuilder(260);
StringBuilder stringColorName = new StringBuilder(260);
StringBuilder stringSizeName = new StringBuilder(260);
Int32 s = GetCurrentThemeName(stringThemeName, 260,stringColorName, 260,stringSizeName, 260);

After taking a look at the MSDN documentation it looks like GetThemeDocumentationProperty might be what you are looking for.
You'll want to use it in conjunction with the theme file (which you alreayd have found in the registry) as well as by passing in the SZ_THDOCPROP_DISPLAYNAME as the second parameter of the method.
In addition here is a site that has the c# method wrapper for the p/invoke call: http://www.java2s.com/Open-Source/CSharp/2.6.4-mono-.net-core/System.Windows.Forms/System/Windows/Forms/VisualStyles/UXTheme.cs.htm
Hope that helps.

Why can't I get GetPrivateProfileString to work via pinvoke?

Running a c# console app I wrote on 64 bit Vista. Here's the code:
class Class1
{
static void Main(string[] args)
{
Debug.Assert(File.Exists(#"c:\test.ini"));
StringBuilder sb = new StringBuilder(500);
uint res = GetPrivateProfileString("AppName", "KeyName", "", sb, sb.Capacity, #"c:\test.ini");
Console.WriteLine(sb.ToString());
}
[DllImport("kernel32.dll")]
static extern uint GetPrivateProfileString(string lpAppName, string lpKeyName, string lpDefault, StringBuilder lpReturnedString, int nSize, string lpFileName);
}
I'm sure I'll get a big "DUH!" for an answer, but I'm not seeing why this fails to work. Other than the Debug.Assert, this code was cut from the c# sample at this page

This one has been busting my chops all day, too. I think I found a work-around, which I really don't want to have to deal with: insert a blank line before the first section header in your .ini file. Now run your app and see if you don't start seeing the values you were expecting.
Considering this bug has apparently been around for years, I'm surprised MS hasn't fixed it by now. But then, .ini files were supposed to have gone away years ago. Which of course is funny, because there are a lot of places MS uses .ini file (e.g, desktop.ini). But I think MS is aware of the bug, because I notice my desktop.ini files include a leading blank line. Hmmm...

The main thing I see is that you should be passing in an uint for nSize, as well as the return value. This is because the return and nSize parameters of GetPrivateProfileString are DWORD values, which are unsigned 32bit integers.
I personally have used the syntax on PInvoke.net:
[DllImport("kernel32.dll", CharSet=CharSet.Unicode)]
static extern uint GetPrivateProfileString(
string lpAppName,
string lpKeyName,
string lpDefault,
StringBuilder lpReturnedString,
uint nSize,
string lpFileName);
In addition, you'll need to put the full path to the file in place, unless the file is located in the Windows directory. From the docs:
If this parameter does not contain a full path to the file, the system searches for the file in the Windows directory.

According to pinvoke.net, nSize should be a UINT. Also they are using an absolute path in their example.
Other than those differences, I can't see anything else.
Providing it's throwing a invalid format exception, try setting target platform to x86 to solve the problem.
Usage example from pinvoke.net is
[DllImport("kernel32.dll", CharSet=CharSet.Unicode)]
static extern uint GetPrivateProfileString(
string lpAppName,
string lpKeyName,
string lpDefault,
StringBuilder lpReturnedString,
uint nSize,
string lpFileName);
static void Main(string[] args)
{
StringBuilder sb = new StringBuilder(500);
uint res = GetPrivateProfileString("AppName", "KeyName", "", sb, (uint)sb.Capacity, #"c:\test.ini");
Console.WriteLine(sb.ToString());
}

If no path is specified, GetPrivateProfileString will look for Test.ini in the Windows directory.
Old APIs like GetPrivateProfileString don't handle Unicode well (even though there's a GetPrivateProfileStringW function). If Test.ini contains a UTF header or Unicode characters, that might be enough to prevent GetPrivateProfileString from working correctly.
Also, Vista's UAC can make handling files that are in "special" places tricky (C:\, C:\Windows, C:\Program Files, etc.). Try putting Test.ini in a folder rather than in the root of the C: drive, or turn off UAC. There's a thread on CodeProject that discusses GetPrivateProfileString failing silently when trying to read an .ini from a folder controlled by UAC.

Maybe you should look into looking at an open source solution that will do exactly that without you worrying about p/Invoke's. The project targetted for .NET is called nini I am using this in a project I am working on and I recommend it.
Hope this helps,
Best regards,
Tom.

Can you verify the contents of your test.ini file? Given all of the steps that you've tried, I'm beginning to suspect that your data file is not formatted correctly (misspelling, etc.) In other words, GetPrivateProfileString may be "working", but just not finding your string. Based on the code that you posted, your test.ini file should look something like this:
[AppName]
KeyName=foo