In self-contained app Application.ExecutablePath returns dll

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?

[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.

[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.