FsXaml 2.0 Beta

Please consider testing out the new prerelease of FsXaml 2.0, and leaving comments and ideas below.

NuGet package published at https://www.nuget.org/packages/FsXaml.Wpf/2.0.0-beta1

This release includes significant improvements to the generated code related to all XAML types. The containers and factories no longer exist - loading XAML files into a generated type is much more aligned with the results from C# code generation (with some differences, described below).

Major Changes

• UserControl types no longer are wrapped within a ContentControl when loaded from XAML. The “root” of the visual tree is the control itself, which means better efficiency, but also eliminates some of the bugs present in the previous version of FsXaml.
• Application and ResourceDictionary no longer use factories. The XAML<> provider creates the Application or Resource Dictionary subclass directly. This is a breaking change from previous version - for example, instead of App().Root.Run() you just do App().Run().
• The IViewController and specific view controller classes have been removed. The ViewController types in previous versions were intended as a way to duplicate “code behind” style functionality. Since we now create types directly, and have flagged them as inheritable, you can write code behind directly in a subclass. Detailed examples exists in the demos. For an example, see: https://github.com/fsprojects/FsXaml/blob/master/demos/WpfSimpleMvvmApplication/MainView.xaml.fs#L5-L18
• FrameworkElement types automatically load all named elements. The 2nd static parameter to the type provider has been removed, and is automatically treated as if it were true. Types without named elements do not create the accessors or incur extra overhead, as the type provider handles the checking internally.
• ResourceDictionary types (and Application) no longer create elements for items by x:Key. You can create a resource dictionary, but need to access it as a dictionary (which is more aligned with C#).
• Added Wpf module with utilites which allow for installation of synchronization context prior to creating the application. This is required if doing asynchronous work within types that are generated directly from the main windows

Breaking Changes

• The factory type removal means removing the extra .Root from application and resource dictionaries.
• ViewControllers no longer exist. Convert to using code behind directly.

Known Issues

• Use of code behind from within the main, startup window does not work. The easy workaround is to create the main window in code, such as in this demo: https://github.com/fsprojects/FsXaml/blob/master/demos/WpfMvvmAgent/App.fs#L9-L10
• Visual F# Power Tools will report erroneous errors when subclassing generated types from a type provider. Every use of code behind causes 3 errors to show up if Power Tools is enabled. (The compiler handles it fine, and doesn’t report errors, but if power tools is enabled, you get 3 that show up after compile, and red squigglies in the editor.)

Tasks prior to 2.0 RTM

• Report issue with Visual F# Power Tools and inherting from generated types
• See what can be done about #24
• Handle issue #34
• Migrate supplied behaviors to attached properties Moved to future in #35
• Remove dependency of Expression.Blend.Sdk
• Optional: Ship behaviors as separate NuGet/Project? (Please comment on whether Blend support is important to you - or this may be dropped)

Please try the new package, and let me know of any issues, ideas, or improvements that need to happen prior to 2.0.

Thank you! Reed

[ReedCopsey]

@brianberns Just realized - you can actually fix it now if you want. The pull request generates a new vsix. If you want to fix it immediately, you can install the vsix from VFPT at https://ci.appveyor.com/project/dungpa/visualfsharppowertools/build/2.5.0-a1605170311/artifacts

[brianberns]

Yep, that’s exactly what I’m seeing. Thank you.