Top-level statements and WindowsApplicationBuilder

[LeftTwixWand]

Hi WindowsAppSDK team and community 👋

With .NET 6 we got some improvement in the code structuring: top-level statements, that allows us to have "empty" Program.cs file.
So, the Program.cs file in ASP.NET Core apps now looks like this:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var app = builder.Build();

if (app.Environment.IsDevelopment()) {
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();

app.UseAuthorization();

app.MapControllers();

app.Run();

In MAUI MauiProgram.cs now looks this way:

public static class MauiProgram
{
    public static MauiApp CreateMauiApp()
    {
        var builder = MauiApp.CreateBuilder();

    	builder
            .UseMauiApp<App>()
            .ConfigureFonts(fonts =>
	    {
		fonts.AddFont("OpenSans-Regular.ttf", "OpenSansRegular");
		fonts.AddFont("OpenSans-Semibold.ttf", "OpenSansSemibold");
	    });
		
	return builder.Build();
    }
}

As a software engineer, I would like to see something similar in WindowsAppSDK projects.
So my propositions are:

• To add the Program.cs file
• To introduce WindowsApplicationBuilder

And the code should look like this:

var builder = WindowsApplication.CreateBuilder(args);

builder.UseApp<App>();

var app = builder.Build();

await app.StartAsync();

Ideally, the WindowsApplicationBuilder should implement IHost interface to be able to use Microsoft.Extensions.Hosting for further configurations, like Logging, Configuration, Dependency Injection and so on.
Because, from my point of view, modern desktop development process is underdone.
And with such approach it will be more convenient for new users what to do. Dotnet in WindowsAppSDK will look like in other modern dotnet-family projects.

---

CONS:
The only one minus that I'm thinking of now - is C++ project template.
It will remain the old template structure, which might be a little bit confusing for developers, who are moving from one language to the other.

[LeftTwixWand]

As an additional thought, I'm a little dissatisfied with this infrastructure, that we have in desktop development in generous.
What I mean is when you're starting a new React, Flutter or even Blazor project - it gives you a huge amount of ready to go libraries, so you don't have to write the same code again and again.

And I'm talking about such basic things, like navigation. Each time I'm creating a new project - I have to manually write some NavigationService. (Thanks to TemplateStudio it's not so painful)
Maybe, once I'll have time to create such library for navigation, and the WindowsApplicationBuilder concept would help me a lot.

Because all I want to do is to write:

var builder = WindowsApplication.CreateBuilder(args);

builder.UseApp<App>();

builder.Services.AddNavigation(); // From some library

var app = builder.Build();

app.UseNavigation();
// Or
app.UseNavigation(new MyCustomNavigationProvider()); // From some 3d party library

await app.StartAsync();

[Balkoth]

I hate that top-level-statement bullshit with a passion, a *.cs file had a well defined structure until this got introduced. Adds complexity where it is not needed, so i am against it.

[christosk92]

I do not really like the fact of DI containers being the default of a UI app like this. A lot of times I do not need them, especially when I'm just prototyping something so the extra overhead it adds is useless.

Furthermore this also limits the type of DI container you can use, which will be the MSFT one.

Also how would you handle app activation now from like a notification? I don't think this is good idea.

You can obviously hack your way around to get the app to launch using a standard Program.cs and a main/args constructor, so the option is there if you really need it. I just don't think it's a good idea to bake it in like this.

Also are you really making that many apps, that making a new navigation service (or putting them in your own class lib), takes up that much of your time?

In fact, I think each app is different and would require its own logic for navigation. Some apps should have caching, some should absolutely not etc. This will just promote more bad apps IMO, because people will often opt for the default. Which may or may not be good. We don't know.

[LeftTwixWand]

Hi @christosk92. My point here is that configuration of the app, and its activation should be separate.
App.cs still can be used to handle OnLaunched activity and work with UnhandledExceptions, but not the app configuration.
For it, I want to use Programm.cs, like other modern .NET technologies work.

What about DI containers: if you're writing a simple ToDo app with code-behind - you don't need DI and can skip this step. But in my practice - you would like to set up some DI and inject services into ViewModels for appropriate logging, servicing, communication with external resources and so on.

Furthermore this also limits the type of DI container you can use, which will be the MSFT one.

I don't think so. With concept of WindowsApplication, which implements IHost you will be able to use huge amount of libraries, like:

• Autofac.Extensions.DependencyInjection
• Serilog.Extensions.Hosting
• And many more

var app = WindowsApplication.CreateBuilder(args)
           .UseServiceProviderFactory(new AutofacServiceProviderFactory())
           .UseSerilog((hostBuilderContext, loggerConfiguration) => ...)
           .ConfigureAppConfiguration((hostBuilderContext, configurationBuilder) => ...)
           .Build();

[LeftTwixWand]

One more argument why we need a WindowsApplicationBuilder is testing.
Have you ever tried to write an integration test for a desktop app? If you are - that you understand, how painful it is.
But with WindowsApplicationBuilder we would have a chance to write integration tests in easy way.
Just like ASP.NET Core has the WebApplicationBuilder and WebApplicationBuilderFactory, which allows you to spin up the entire application in memory and mock some services.

Using the same approach, we would be able to write elegant tests for desktop.
Because as I said earlier - the desktop developments in WinForms, WPF, UWP and WinUI now feels underdone.
You can create a simple app, but if we want to see more quality native Windows apps - we need a good infrastructure for it.

[christosk92]

I understand your concerns, and if it really is gonna help a lot of people why not, just please allow us to pick :). Like @Balkoth said, I also really dislike top-level statements.

[LeftTwixWand]

Of course, I'm not pushing anyone to use the exact approach.
I would be happy to have different options of a new project.

[Balkoth]

Imho you are mixing 2 suggestions into one.

Top-level-statements is one of the most controversal features of the current .net era: dotnet/docs#27420
The discussion about it was so effed up that the ticket was just closed by microsoft to not allow further rage about it. And there is no choice now. We are left to deal with it and if we want to have it the way it was before we have to write the code ourselves. The default templates were just changed to the "modern" approach. Any criticism about it was just brushed off.

If you want to use a host, you can do it today already. Just create an IHost where you can register all the services you want and expose them how you need them.

There is one thing this framework does not need. It is more complex features. There is so many stuff that is supported and just does not work under various OS versions and conditions. Visual Studio allows you to compile apps with settings, where the binary crashes on startup. Basic things, like setting a minimum window size are not supported out of the box. If you don't believe me just search for tickets commented by me.

So no, fix the existing bugs first and get stability into the project, before focussing on nice to have things like "ApplicationBuilder".