fix: Application.ExecutablePath returns dll instead of exe (#2801)
#2838
Conversation
RussKie
added
the
servicing-consider
Codecov Report
@@ Coverage Diff @@
## release/3.1 #2838 +/- ##
====================================================
+ Coverage 24.85382% 24.8638% +0.00997%
====================================================
Files 844 844
Lines 260290 260274 -16
Branches 36896 36894 -2
====================================================
+ Hits 64692 64714 +22
+ Misses 190874 190837 -37
+ Partials 4724 4723 -1
|
…2801) In .NET artifacts are DLLs even for executable projects. With some automagic they get bundled into executables. However `Assembly.GetEntryAssembly()` always returns the dll instead of the exe. Following the guidance from the Runtime team retrieve the path to the executable via `GetModuleFileNameW` call. Resolves dotnet#1143 (cherry picked from commit 2af3af9)
RussKie
force-pushed
the
fix_Application.ExecutablePath
branch
from
a17e689 to
abd221b
Compare
| } | ||
| } | ||
| StringBuilder sb = UnsafeNativeMethods.GetModuleFileNameLongPath(NativeMethods.NullHandleRef); | ||
| executablePath = Path.GetFullPath(sb.ToString()); |
There was a problem hiding this comment.
If this does return a relative path at any point, GetFullPath is going to resolve it by whatever the current directory is, which may or may not be the application directory:
C:\>cd NotApplicationDir
C:\NotApplicationDir> C:\MyApp\App.exe
If GetModuleFileNameLongPath actually returns a relative path at any point, this will return C:\NotApplicationDir\App.exe.
There was a problem hiding this comment.
From my reading, it probably doesn't, and you are doing this just to normalize the path, right?
There was a problem hiding this comment.
From my reading, it probably doesn't, and you are doing this just to normalize the path, right?
I believe so too. That's how the original code had it. It may be redundant but I'm not going to change it on a service branch. :)
There was a problem hiding this comment.
doc says
Retrieves the fully qualified path
which rules out relative paths (actually I commented on this on the other PR)
merriemcgaw
removed
the
servicing-consider
RussKie
added
📫 waiting-approval
🚫 * NO-MERGE *
|
This is good for 5.0, but until we find out that it's blocking servicing, I think that this won't meet a servicing bar for 3.1. |
ghost
locked as resolved and limited conversation to collaborators
Resolves #1143
For discussions and tests refer to #2801
(cherry picked from commit 2af3af9)
Proposed changes
In .NET artifacts are DLLs even for executable projects. With some automagic they get bundled into executables.
However
Assembly.GetEntryAssembly()always returns the dll instead of the exe.Following the guidance from the Runtime team retrieve the path to the executable via
GetModuleFileNameWcall.Customer Impact
Regression?
Risk
Test methodology
Application.ExecutablePathreturns dll instead of exe #2801Microsoft Reviewers: Open in CodeFlow