Console application window and buffer sizes in Windows 11

Question

Okay so I have a console application in Windows 11 using .Net-7.0 and not targeting any particular platform

When I go to set the console's window and buffer sizes it does absolutely nothing, and without checking if the operating system is Windows using OperatingSystem.IsWindows() before calling either Console.SetWindowSize([w], [w]) or Console.SetBufferSize([w], [h]) the IDE throws a warning of CA1416 as it isn't a platform specific call.

I have no problem using the IsWindows() check as this is just a test application, but I am trying to output the data in a fixed width and height (such as a REPL application would, but without redrawing the screen). Since I cannot set either the window width OR the buffer width through the System.Console API I would have to implement my own buffer code to accomplish what I am trying to do.

Is this an issue with Windows Terminal vs CMD? How do I accomplish what I am trying to do without bringing in a third party library? Am I stuck having to do some P/Invoke magic to do this?

EDIT: I am unable to change the framework I am targeting at all as the code this program tests requires .Net-7.0

EDIT 2: Upon further diagnosis I have found that a fresh console app targeting .Net Core 3.1 WILL allow me to set the buffer width/height in the following way, however it does NOT modify the window's size at all and does NOT work in .Net-7.0. Only the buffer is actually adjusted, and the call to Console.Clear() is required to make it actually stick.

Console.SetWindowSize(5,5);
Console.SetBufferSize(5,5);
Console.Clear();

@user09938 I only noted that as targeting an older framework might have potentially fixed the issue - I'll remove that note — Robert Petz, Jan 26 '23 at 20:56
According to [Windows Console and Terminal Ecosystem Roadmap](https://learn.microsoft.com/en-us/windows/console/ecosystem-roadmap): _With the support and documentation of virtual terminal sequences on the client side, we strongly encourage Windows command-line utility developers to use virtual terminal sequences first over the classic Windows APIs to gain the benefit of a unified ecosystem with all platforms_. Also see [Console Virtual Terminal Sequences](https://learn.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences). — Tu deschizi eu inchid, Jan 26 '23 at 21:22
@user09938 hmmm, this seems like it makes all of the simplicity of the traditional C# console APIs extremely convoluted to do what it is I'm trying to do in this particular example...I will look further into this but it definitely doesn't answer the question for me here — Robert Petz, Jan 27 '23 at 01:55
Here's another one: [Classic Console APIs versus Virtual Terminal Sequences](https://learn.microsoft.com/en-us/windows/console/classic-vs-vt): _Our recommendation is to replace the classic Windows Console API with virtual terminal sequences...Virtual terminal sequences are natively supported across platforms...By contrast, Windows Console APIs are only supported on Windows_. — Tu deschizi eu inchid, Jan 27 '23 at 04:25

score 2 · Answer 1 · answered Jan 27 '23 at 09:52

According to Classic Console APIs versus Virtual Terminal Sequences:

Our recommendation is to replace the classic Windows Console API with virtual terminal sequences. This article will outline the difference between the two and discuss the reasons for our recommendation.

Definitions The classic Windows Console API surface is defined as the series of C language functional interfaces on kernel32.dll with "Console" in the name.

...

Cross-Platform Support

Virtual terminal sequences are natively supported across platforms, making terminal applications and command-line utilities easily portable between versions and variations of operating systems, with the exception of Windows.

By contrast, Windows Console APIs are only supported on Windows. An extensive adapter or translation library must be written between Windows and virtual terminal, or vice-versa, when attempting to port command-line utilities from one platform or another.

In the OP you've specified Windows Console APIs

Console.SetWindowSize
Console.SetBufferSize

but stated that you're not targeting any particular platform which is why you've received the following message:

CA1416: This call site is reachable on all platforms. 'Console.SetBufferSize(int, int)' is only supported on: 'windows'.

and

CA1416: This call site is reachable on all platforms. 'Console.SetWindowSize(int, int)' is only supported on: 'windows'.

Both messages state: only supported on: 'windows', which means that if you want to use them, you need to target Windows.

To Target Windows (VS 2022):

In VS menu, click Project
Select <project name> Properties
Under Target OS, select Windows

Clean and rebuild.

Also see: Target frameworks in SDK-style projects

The following code is adapted from here and has been tested. It works with .NET 7 after setting the Target OS to Windows.

static void Main(string[] args)
{
    int width = 80;
    int height = 10;

    if (Console.WindowLeft + Console.WindowWidth < width && Console.WindowTop + Console.WindowHeight < height)
        System.Console.SetBufferSize(width, height);

    System.Console.SetWindowSize(width, height);

    for (int i = 0; i < height; i++)
    {
        Console.WriteLine($"line {i + 1}");
    }
}

Additional Resources:

I tested this code provided - the buffer size gets set (regardless of the targeted OS version being 'none' or 'windows', the later clears the `CA1416` warning), but the window size still is unaffected at all — Robert Petz, Jan 29 '23 at 06:08
@RobertPetz: I tested it on Win 10. Unfortunately, I don't have Win 11. — Tu deschizi eu inchid, Jan 29 '23 at 06:24

Console application window and buffer sizes in Windows 11

1 Answers1

Linked