NET 5 cannot produce console app with visible window if it references Windows Forms
See original GitHub issueI have the following code:
consoleapp.csproj
<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.1</TargetFramework>
<UseWPF>true</UseWPF>
<UseWindowsForms>true</UseWindowsForms>
</PropertyGroup>
</Project>
Program.cs
using System;
using System.Windows.Forms;
namespace consoleapp
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello World!");
for (;;)
{
var input = Console.ReadLine();
System.Console.WriteLine("Got " + input);
if (input == "form")
{
Form frm = new Form();
Button btn = new Button()
{
Left = 120,
Width = 130,
Height = 30,
Top = 150,
Text = "OK"
};
frm.Controls.Add(btn);
frm.ShowDialog();
}
}
}
}
}
Under Net Core 3.1.302, dotnet build
produces an .exe that when double-clicked in Windows Explorer, starts the app with a visible window.
Under Net 5.0.100, dotnet build
produces an .exe that when double-clicked in Windows Explorer, starts the application but there is no visible window.
In the documentation, it notes “* Starting in .NET 5.0, Windows Forms and Windows Presentation Foundation (WPF) projects should specify the .NET SDK (Microsoft.NET.Sdk) instead of Microsoft.NET.Sdk.WindowsDesktop. For these projects, setting TargetFramework to net5.0-windows and UseWPF or UseWindowsForms to true will automatically import the Windows desktop SDK. If your project targets .NET 5.0 or later and specifies the Microsoft.NET.Sdk.WindowsDesktop SDK, you’ll get build warning NETSDK1137.” Following those instructions–and many permutations with/without .WindowsDesktop
, TargetFramework
, UseWPF
, UseWindowsForms
–there is nothing that I can do to produce a console app that, when double-clicking on the .exe, has a visible window for NET 5.
This is a problem because when the .csproj is opened in VS2019.8 and the program debugged via F5, there is no window. (It is actually worse in my application because a Read() from stdin return EOF=-1, just because there really is no visible/attacted window for a CLI prompt. I could start the program in a cmd.exe terminal, then attach the debugger to my program, but this is a royal pain, and I have to insert Sleep() calls at the start of the program if I want to debug start up code.) If I click on Properties for “consoleapp” in the Solution Explorer in VS2019.8, the “Output type” is “Windows Application”, I change the “Output type” to “Console Application”, then save. After closing and reopening, I re-display the the properties for the program–it’s stuck at “Windows Application”.
This is a console application that requires a window because it’s a CLI program. On some commands, it will pop open a Windows Form. I can start the program in a console window, but I cannot debug the program startup because there is no visible window.
The actual use case is my program Trash, a Bash-like shell but for parsing, parse trees, grammar refactorings, compiler development, where I want a console application that can occasionally display decorated parse trees using Automatic Graph Layout. For the moment, the AGL display is in-process, but I may move to an out-of-process command set if I can pass huge trees between processes with fast IPC. But I am not hopeful because parse trees are frigging huge.
Is there a way of setting up the csproj file–or elsewhere–so that I get a visible window? Why does VS2019.8 think this is a Windows Application? Does the Output set to “Exe” mean anything? Why does VS2019.8 application settings for Console Application not stick?
(As I note in a follow-up comment, setting up a global.json file for 3.1.302 is a workaround. However, I’d like to move forward to NET 5.)
–Ken Domino
Issue Analytics
- State:
- Created 3 years ago
- Reactions:8
- Comments:20 (1 by maintainers)
Top GitHub Comments
This looks to be intentional. See https://docs.microsoft.com/en-us/dotnet/core/compatibility/windows-forms/5.0/automatically-infer-winexe-output-type
To revert to the old behavior, you can set this property in the .csproj file:
“Reason for change” : Break production 3.1 apps and waste peoples time - ticking time bomb for loads of people the next time they rebuild their 3.1 app on DevOps. (like I did today)