Revert DisableWinExeOutputInference

[batzen]

With #11398 the OutputType a user explicitly sets in his projects is ignored, except when he sets DisableWinExeOutputInference.

This is not acceptable and was not asked for by the community.
#11398 was not discussed and the feedback given there was simply ignored.

We now have a very, very confusing behavior where the users explicit choice of setting OutputType to exe is completely ignored.

Please see the following issues for reference:

• UseWindowsForms='true' with OutputType='Exe' produces GUI instead of CUI executable  #13331
• Can't (easily) build a Windows console app that accesses the clipboard #13624
• Wpf Application switches to WinExe, not only in Net5, also in a 4.6.1 wpf#4314
• WPF .NET Core - Console Application doesn't open console wpf#4138
• https://developercommunity2.visualstudio.com/t/WPF-NET-Core---Console-Application-does/1289479

There wasn't even an explanation why this should be changed in the first place.
The reasoning in the documentation at https://docs.microsoft.com/de-de/dotnet/core/compatibility/windows-forms/5.0/automatically-infer-winexe-output-type states "It's assumed that most users don't want a console window to open when a WPF or Windows Forms app is executed".
May i ask who assumes this because of which issues?
Was this requested by someone? #11398 did not mention any users/issues identifying this as an issue.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[jogibear9988]

This was the Pull req. #12152

[marcpopMSFT]

Thanks for the feedback.

We should have limited this change to only projects targeting 5.0 and newer so we did not affect existing projects. We have rectified that going forward: #16472. This was an attempt to fix existing apps that used templates that incorrectly defaulted to OutputType=Exe for a Windows Desktop application. That application type should not have default behavior for including the console window spawning. There are many scenarios that customers would still want the console window but we did not want that to be the default behavior. As mentioned in the link you included, we also want to align around OutputType going forward for multi-targeting to other platforms that don't support winexe.

[jogibear9988]

@sfoslund @marcpopMSFT
have you read all the complains? for example also the ones in my ticket? dotnet/wpf#4314
Also if it is not the default any more, how could the user switch to console via the visual studio UI? what is the user experience if he changes a dropdown, and after that the value jumps back?

[batzen]

@marcpopMSFT Closed? Really?
I am using multi targeting. If this would only have changed for .NET 5 it would have been even worse. Oh, you just did that without further discussion.

So the reason for this change was a mistake in some templates?
Changing the SDK in such a way just to mitigate some template mistake is really strange. By trying to fix it this way you broke many more existing apps...

As @jogibear9988 pointed out, how are users supposed to switch to exe instead of winexe using just the Visual Studio UI?

I still think the changes should be reverted.

[vatsan-madhavan]

@marcpopMSFT Will the final design always respect OutputType set by the developer explicitly without qualification/exceptions and requiring any extra work (like setting extra properties)? If not would you mind clarifying what the exceptions and the respective rationale are?

[jogibear9988]

Thats the User experience now...

Switch to Console, open again, and voila it's switching back....

[dsplaisted]

We have heard the feedback. I know there are a lot of different issues on this, so most people probably didn't see my explanation here: dotnet/docs#21952 (comment)

The change wasn't made to support existing templates. It was a forward-looking change, so that .NET Maui app projects could specify a single OutputType for Windows, iOS, and Android. We wanted to avoid having something like this in the project file:

    <OutputType>Exe</OutputType>
    <OutputType Condition="'$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)'))' == 'Windows'">WinExe</OutputType>

For .NET Maui, we are still considering what the right design is. Right now what we would like to do is create a new OutputType of App that will translate to Exe or WinExe depending on the target platform. However, we're not yet sure how well that will work. We are sure that we should not have made the change to translate Exe to WinExe to projects targeting .NET Framework or .NET Core 3.x, so we are fixing that for .NET SDK 5.0.300, which will ship with Visual Studio 16.10. If we are able to make the App output type work well, then we will probably also remove the inference from Exe to WinExe altogether

how are users supposed to switch to exe instead of winexe using just the Visual Studio UI?

For Sdk-style projects (the only ones affected by this change), you can edit the project file in Visual Studio (without unloading). You can double-click on the project in the Solution Explorer to open the project file, or right click on it and select "Edit Project File". Then you can add the following property:

<DisableWinExeOutputInference>true</DisableWinExeOutputInference>

[vatsan-madhavan]

Thanks @dsplaisted. I'm assuming that inference only applies when OutputType is left unspecified ?

And whenever OutputType is explicitly specified, there will be no inference (irrespective of project style, SDK version etc.) that silently overrides that specified OutputType with some other value - and in turn expects the developer to understand this is what's going on, puzzle out how to remedy it if its not to their liking, then find the suitable remedy from one of these GitHub issues, apply it etc. ?

[jogibear9988]

@vatsan-madhavan

No you're wrong. And that's the issue I have with it.

You can specify the output type (select in Visual Studio UI the "Console Application"), close the settings, and when you open them again they are reverted.
I think if you leave it like this, you should add "DisableWinExeOutputInference" automaticaly when the outputtype is changed via Visual Studio UI, or add an Info text (as I showed in my isse about this)

[vatsan-madhavan]

@jogibear9988 I'm sorry I'm not sure what I'm wrong about - I just asked a couple of questions (i.e., I didn't make any assertions). The second question could perhaps have been phrased a bit more like a question and a little bit less like an assertion... ☮️

[jogibear9988]

@vatsan-madhavan that there is only inference when output type is not specified.

You can specify it, but you need to add "DisableWinExeOutputInference" that your specfied type will be used.

[batzen]

@dsplaisted If this is done to support MAUI and use "exe" on platforms that are not windows, why isn't it done that way?

Assuming "winexe" only applies to Windows and does not exist on ios or android it would be logical to translate "winexe" to "exe" on those platforms.

[batzen]

And it should not depend on UseWPF or UseWindowsForms as there are other UI frameworks like Avalonia.

[acaly]

I think if you leave it like this, you should add "DisableWinExeOutputInference" automaticaly when the outputtype is changed via Visual Studio UI, or add an Info text (as I showed in my isse about this)

Agreed. Really hope this UI can be improved in the future. This is very frustrating at the beginning indeed. Thankfully there is Bing (or Google) that let me know about this issue.

No matter how it interferes with MAUI, I think at the end there should still be an option to open the console window so that we can easily inspect debugging info printed from the convenient Console.WriteLine.

[dsplaisted]

Hi folks,

Sorry for the inconvenience this caused. We've reverted the change for .NET 6: #19651