Use Environment.ProcessPath instead of Process.GetCurrentProcess().Pr…

[NeverMorewd]

Fixes #

Main PR

Description

Replace Process.GetCurrentProcess().ProcessName with Path.GetFileNameWithoutExtension(Environment.ProcessPath) for better performance and cleaner code.

Customer Impact

• Reduced system call overhead
• No temporary Process object creation

Regression

Testing

Risk

Microsoft Reviewers: Open in CodeFlow

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 13.42425%. Comparing base (725fc8a) to head (eec8f43).

Additional details and impacted files

@@                 Coverage Diff                 @@
##                main      #10998         +/-   ##
===================================================
- Coverage   13.42545%   13.42425%   -0.00120%     
===================================================
  Files           3319        3319                 
  Lines         664894      664894                 
  Branches       74674       74674                 
===================================================
- Hits           89265       89257          -8     
- Misses        573084      573092          +8     
  Partials        2545        2545                 

Flag	Coverage Δ
Debug	13.42425% <ø> (-0.00120%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[lindexi]

Environment.ProcessPath will call the Kernel32.GetModuleFileNameW, see https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-getmodulefilenamew

System.Diagnostics.Process.GetCurrentProcess().ProcessName will call Kernel32.QueryFullProcessImageNameW, see https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-getmodulefilenamew

I do not think this is the same behavior. But I believe it is the same behavior in the vast majority of cases.

[NeverMorewd]

Process.GetCurrentProcess() without using will left a Process instance after each calling.
In certain scenarios with high call volume, this pr will make sense.

[Symbai]

But I believe it is the same behavior in the vast majority of cases.

For WPF both .NET APIs return the same result. There is no difference. Only for other .NET scenarios (not WPF related: framework dependend when running from dotnet.exe, browser etc) there is a difference between Environment.ProcessPath and ProcessName. Yes, they call different winapis but for WPF the result is the same in all cases.

[miloush]

One difference is when the file is renamed while the process is running. But the discussion is moot as per the PR discussion.

[miloush]

I agree this is a compatibility risk.

[lindexi]

@miloush This is the edge module code, and it only effect the log message. So that I think it is ok.

[miloush]

Which should be discussed in the issue description, together with how it was tested. You have to have a special build with LOGGING set, so the impact of this change is questionable.

[lindexi]

@miloush I think it is the debug code.

[jizc]

Just want to point out that the contents of the Log method that msg is sent to has been commented out.

wpf/src/Microsoft.DotNet.Wpf/src/Shared/MS/Win32/ManagedWndProcTracker.cs

Lines 224 to 235 in 725fc8a

	private static void Log(string msg)
	{
	//DbgUserBreakPoint();
	/*
	byte[] msgBytes = System.Text.Encoding.ASCII.GetBytes(msg);
	System.IO.FileStream fs = System.IO.File.Open("c:\\dwplog.txt", System.IO.FileMode.Append, System.IO.FileAccess.Write, System.IO.FileShare.ReadWrite);
	fs.Write(msgBytes, 0, msgBytes.Length);
	fs.Flush();
	fs.Close();
	*/
	}