UseWindowsForms='true' with OutputType='Exe' produces GUI instead of CUI executable

In the old .csproj format, setting <OutputType>Exe</OutputType> produced an executable that is a console application, even if WinForms was used in the application. Similarly, <OutputType>WinExe</OutputType> always produced a windows GUI application. There are times when a console application is desired, though I’d agree not most times.

This old behavior can be easily confirmed by creating a legacy WinForms project, compiling it with both OutputTypes and running dumpbin /headers MyApp.exe and looking in the output for subsystem. The results are 3 subsystem (Windows CUI) for Exe and 2 subsystem (Windows GUI) for WinExe. Pay attention of the C vs G in that output - it is easy to miss.

After converting to the new SDK format csproj for multitargeting support (as we all want to move to .NET 5.0 but it does not happen overnight), this behavior is broken in the full framework (net48) project - but only if the ‘WindowsDesktop’ is used and/or ‘UseWindowsForms’ is true. I’d consider this a regression.

The following project will generate, always, the equal of OutputType == WinExe regardless of what is specified . This is easily confirmed by dumpbin on the output of compilation with both settings.

<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
  <PropertyGroup>
   <TargetFrameworks>net48;netcoreapp5.0</TargetFrameworks>
   <UseWindowsForms>true</UseWindowsForms>
   <OutputType>Exe</OutputType>
  </PropertyGroup>
</Project>

The following project, without WindowsDesktop and/or UseWindowsForms the OutputType is respected, and will produce an executable with the expected subsystem. Confirmation achieved with the above process.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
   <TargetFrameworks>net48;netcoreapp5.0</TargetFrameworks>
   <OutputType>Exe</OutputType>
  </PropertyGroup>
</Project>

If your application does use WinForms, adjusting the project to look like the latter example results in failed compilation., as one would expect.

The only workaround I have been able to discover is not a reasonable one. A post-build step to run editbin /subsystem:console MyApp.exe to twiddle the appropriate bits in the PXE header will make the compiled output behave as desired. To fully/properly integrate this type of workaround in the build pipeline would require something along the lines of Kirill Osenkov’s LargeAddressAware package.

Is there a better workaround to restore the previous, and desired, behavior, making the specified OutputType consistent and predictable regardless of what SDK or UseXYZ was also in the project?

[StevenBonePgh]

I still say this is a regression as it is a breaking behavior change. Also, the word Inference is defined as ‘a conclusion reached on the basis of evidence and reasoning’ Reasoning that the output type should not be EXACTLY as the user specified (the evidence) is a bug in your inferencing logic. If the user was silent on the output type, then I agree with the remainder of the logic.

[Kryptos-FR]

@sfoslund can this “purposeful change behavior” be reverted?

I have working on a .NET framework project that uses the new “sdk-style” format and having this break overnight with no code changes (just because I updated Visual Studio and installed a new SDK) is not acceptable. That is a breaking change and usually the rule is not have breaking changes.

The fact that the code change was made before the doc is updated (see https://github.com/MicrosoftDocs/visualstudio-docs/issues/5893) is also bad practice. I had no way to know that change and only found the issue by chance. In my team we have a rule that the doc should be updated before the code is merged. Microsoft should follow such practice.

At the very least it should have only affected project targeting net5-windows and not .NET framework or .NET Core 3.1.