scarletkuro / microsoft.extensions.hosting.wpf Goto Github PK

Current documentation is clumsy, I'm trying to move the documentation to Wiki page and make it more logical, but I'm really not good at writing documentation, so if anyway will be interested to help, it will be really welcome.
Also, kind of struggling to cover all the functionality and exceptions via the documentation.
P.S. As alternative to Wiki, the readthedocs.org or something like that could suit too.

We need some improvement to have less "leaky" public abstractions, and reduce the amount of .Something<App>() extensions where it's not needed since it's getting too infectious.
There is also need of some CI/DI.

List of improvements:

• Add Nuget Source Link support.
• Make WpfContext<TApplication> internal and introduce instead IWpfContext<TApplication> → non-genric IWpfContext.
• Make WpfThread<TApplication> internal and introduce instead IWpfThread<TApplication> → non-genric IWpfThread.
• Introduce AddThreadSwitching against AddThreadSwitching<TApplication> in Microsoft.Extensions.Hosting.Wpf.Threading with the help of the new abstractions.
• The UseWpfLifetime<TApplication> will be also replaced to just UseWpfLifetime.
• Add IWpfComponent to be able to hookup new components at wpf thread start, not only tray icon.
• Move ITrayIcon to separate package Microsoft.Extensions.Hosting.Wpf.TrayIcon.
• Add alternative to UseWpfViewModelLocator and IViewModelLocatorInitialization. The sample HostingReactiveUISimpleInjectorFlowingScope shows that there is alternative to the Locator to inject viewmodels to view, but the IViewModelLocatorInitialization.Initialize was used in sample in order to bootstrap ReactiveUI but doesn't set the locator as it says in guide. This can overall confuse the developer.
• Remove IViewModelContainer. A redundant interface which is not really needed to use 3rd party containers. It's adding confusion an can be dangerous if misused.
• Remove new constraint from TApplication in a classes / methods.

Pull Request #9 added support for .NET Framework 4.6.2 and .NET Framework 4.8 by adding net4.6.2;net4.8 as TargetFrameworks

Instead, we can use netstandard2.0 to support those, just like CommunityToolkit.Mvvm (as example) does.

As for now, I will leave it as is. But when .NET 8 will release then I'm going to change this.

Investigate the EnableDefaultApplicationDefinition. As I understand this should stop the automatic generation of the application entry point (Main method) which should make some things easier.

If add the .NET Framework support (#9), strong naming assembly need all dependencies have strong naminged