Add a generic host lifetime for Windows Forms

[alex-oswald]

Enterprise customers want to keep using Windows Forms, and we want to use the generic host.

Can we add a feature to use the generic host with Windows Forms and use the lifetime of the start up form such as this library I created?

https://github.com/oswald-technologies/WindowsFormsLifetime

https://github.com/dotnet/extensions/issues/2949

Benefits this functionality will provide to Windows Forms customers.
The main benefit: allows WinForms developers to easily utilize .NET Core's generic host and have the host gracefully shutdown when the start form is closed.
This in turn lets you use the default host builder in the same way it is used for ASP.NET Core applications.
Further, this allows the use of dependency injection, configuration, logging, and more in WinForms applications without manual setup.

What use cases it will enable, and where it may not be appropriate.
Use dependency injection, configuration, logging with WinForms (and a lot of other .NET Core extensions).
Run background tasks in WinForms with IHostedServices.
Run the GUI on a separate thread to increase performance.

Performance implications.
Using a WindowsFormsLifetime should help increase performance because the WinForms GUI will by default, run on a separate thread. Typically now, you start with the default WinForms template, which runs everything on the GUI thread. I believe most people usually run with this instead of spawning other threads for work. Especially in the Enterprise realm, where we develop WinForms apps quickly for internal use only.

How it would coincide with the VS Designer, etc.
This has a direct correlation with the VS Designer because it is intended to be used with Forms.

My suggestion is to have this be its own extension package, similar to:
https://github.com/dotnet/extensions/tree/master/src/Hosting/WindowsServices

[RussKie]

Thank you, it looks very interesting.

However to take it further we'd appreciate it if you filled the provided template and explained the following:

• benefits this functionality will provide to Windows Forms customers,
• what use cases it will enable, and where it may not be appropriate,
• performance implications,
• how it would coincide with the VS Designer, etc.

As you may understand we can't depend on 3rd party packages for a number of reasons (e.g. security and reliability). This means the proposed functionality will have to be built-in to Windows Forms codebase. In order to do so, the following will need to go through the following steps:

• we will need an API proposal discussing the above points,
• the API will need to be reviewed by our team and @terrajobst team,
• the API will need to be implemented (by our team, by your or another contributor, or a combination of both),
• (likely) the API will need to undergo a useability study,
• the API will need to be documented.

This is an involved process, and I am happy to work with you, if you think the API you are proposing will be useful to Windows Forms users world-wide.

[JeremyKuhne]

@oswaldtech Thanks for your effort on this! It would help if you could give code examples in this issue. That would help us and the API review team understand the need and general usefulness of the API. Specifically:

• Code that shows the surface area of the API.
• Code that shows real world scenarios, and how they would otherwise be handled.
• Details showing the usage/consumption of the proposed new package, and alternatives (e.g. not having this be a separate package).

We'd also need some sort of appraisal/estimate of startup impact, if any.

Here is the link on the API review process. It has a link to a good API proposal that can help.

Most of the people looking at this (including me) won't be intimately familiar with the hosting APIs, so try and write to that audience.

One final (but important) note, adding a new library and package isn't a trivial cost, so it would need to be very clear that the demand is high enough to bring this in as opposed to relying an external package (your library in this case).

[ghost]

This submission has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 14 days.

It will be closed if no further activity occurs within 7 days of this comment.

[merriemcgaw]

@alex-oswald - if this is something you're still interested in pursuing, could you please follow the instructions @JeremyKuhne sent above"

Thanks for your effort on this! It would help if you could give code examples in this issue. That would help us and the API review team understand the need and general usefulness of the API. Specifically:

Code that shows the surface area of the API.
Code that shows real world scenarios, and how they would otherwise be handled.
Details showing the usage/consumption of the proposed new package, and alternatives (e.g. not having this be a separate package).
We'd also need some sort of appraisal/estimate of startup impact, if any.

Here is the link on the API review process. It has a link to a dotnet/runtime#15725 that can help.

Most of the people looking at this (including me) won't be intimately familiar with the hosting APIs, so try and write to that audience.

One final (but important) note, adding a new library and package isn't a trivial cost, so it would need to be very clear that the demand is high enough to bring this in as opposed to relying an external package (your library in this case).

I'll reopen the issue and see where this goes.

[bxjg1987]

anythins?

[ghost]

This submission has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 14 days.

It will be closed if no further activity occurs within 7 days of this comment.

[alex-oswald]

@alex-oswald - if this is something you're still interested in pursuing, could you please follow the instructions @JeremyKuhne sent above"

Thanks for your effort on this! It would help if you could give code examples in this issue. That would help us and the API review team understand the need and general usefulness of the API. Specifically:

Code that shows the surface area of the API.

Code that shows real world scenarios, and how they would otherwise be handled.

Details showing the usage/consumption of the proposed new package, and alternatives (e.g. not having this be a separate package).

We'd also need some sort of appraisal/estimate of startup impact, if any.

Here is the link on the API review process. It has a link to a dotnet/runtime#15725 that can help.

Most of the people looking at this (including me) won't be intimately familiar with the hosting APIs, so try and write to that audience.

One final (but important) note, adding a new library and package isn't a trivial cost, so it would need to be very clear that the demand is high enough to bring this in as opposed to relying an external package (your library in this case).

I'll reopen the issue and see where this goes.

Yup. I'll start spinning cycles after the holiday break.

[alex-oswald]

@merriemcgaw It's been a busy few months at work but my API proposal is done. Shall I create a new issue with the proposal? Or update the original post?

[merriemcgaw]

We added an issue template for the purpose of API Suggestions. I'd probably recommend filing the new issue with the required information. Then link this issue to it and I'll close this as a duplicate. Please be aware we have to follow the API Review process to get it reviewed by .NET API reviewers and follow their recommendations.

[alex-oswald]

API Proposal #11415
Add WindowsFormsLifetime extensions to the .NET Generic Host

[elachlan]

Closing in favor of #11415