In self-contained app Application.ExecutablePath returns dll

[shutdown256]

I'm not sure if this is bug or by design but in a self-contained app Application.ExecutablePath return path to dll and there is no apparent way to easily get path to the executable. What is recommended way to solve this problem?

[Symbai]

I've noticed this too. I believe the executable, considering its tiny size, is just a wrapper hosting your application which is basically still the DLL. So the path of the executable of your application is the path to your dll. To me it looks like an expected behavior which is by-design.

By the way it also links to your DLL when not self contained.

[weltkante]

I don't think its by design, but rather a side effect of .NET Core handling things differently. Application.ExecutablePath already has code to figure out the native entry point but in Desktop Framework the entry point is always in an exe because the native code to load the framework is in the OS. With .NET Core they need to have a loader separate from the OS so the entry point is in a DLL, which didn't really happen in Desktop Framework unless you were implementing a custom native runtime host (and then you already know how your application is named because you implemented the host).

I think this should be fixed, this property is commonly used when you want to restart the application, otherwise there should be an alternate API for this common use case so you don't have to fall back to unmanaged code.

@shutdown256 you can implement this yourself by invoking the unmanaged GetModuleFileName API.

[Symbai]

You don't have to fall back to unmanaged code. You simply use Path.ChangeExtension on the return of Application.ExecutablePath. I would consider it as a breaking change similar to the behavior of Process.Start where on .NET Framework it automatically uses shellexecute while on core it does not. Which means if you do Process.Start("explorer.exe") it works in .NET framework but not in .NET Core, which also was confirmed as "by design".

[weltkante]

Well, the decision with Process.Start was that they wanted it to behave the same on all platforms, but only Windows has the ShellExecute support, so whatever choice they took it was going to be broken from the start.

The case here is different, the implementation already has code to look for the "right" return value (return the native exe e.g. when your DLL is running as a plugin in a native application) but it isn't triggered because what was previoulsy an edge case is now the common case (most people didn't write a native host which calls a main function, now you get one auto-generated).

Whether you consider it a breaking change depends on what you consider your input. If you consider the input "being a managed application" then fixing the bug is no breaking change for this input, but keeping the current behavior is a breaking change for this input. Since dotnet 3 hasn't been released and this is new API there is no breaking change within .NET Core either. The WinForms team can of course still close the issue as 'by design' but I think its possible to still fix this now.

Scenario	Desktop Framework	.NET Core current	.NET Core with fix
managed application	EXE	DLL	EXE
native application calling managed Main	DLL	DLL	EXE
native application calling other managed code (e.g. plugins or COM objects)	EXE	EXE	EXE

I'd consider row 2 to be a bug in Desktop Framework, but it was an edge case so nobody ever bothered to fix it. The fact that .NET Core makes row 2 the default is unfortunate but still fixable without negative impact for the common case.

[Symbai]

This "fix" would need to be a windows - only thing then. So it would behave differently on different OS, which you said, was the goal why shellexecute was changed, although it's a huge breaking change as it's literally never set manually to true in most source codes I've seen.

That was my thought of why this behavior could be a "by design" decision. I'm not saying that a fix doesn't make sense, rather than I believe it's not a bug but just a thing like shellexecute where, when you came from framework development you now need to deal with.

[weltkante]

@Symbai The code for Application.ExecutableImage in WinForms is already Windows only anyways, and the Application class won't be going cross-platform anytime soon either because it is based on the Windows message loop. For cross-platform there is Assembly.GetEntryAssembly and I don't suggest to change that.

[merriemcgaw]

This issue is a dup of dotnet/runtime#3704

[weltkante]

@merriemcgaw are you sure? we are talking about WinForms API here, unless .NET Core changes the entire approach and no longer uses a stub exe, WinForms needs to adapt to the way .NET Core handles things.

Right now the implementation in WinForms is broken because it looks at the stub and doesn't recognize it as a managed application, thus is fooled into taking the wrong code path.

[RussKie]

I don't get an impression this is an issue for the Core Runtime to fix it, and it is up to us to deal with it.