7

I just converted one of the FsXaml demo programs to an interpreted F# script so I could experiment with it and learn. It wouldn't run, and the interpreter gave me the following error message:

System.NotSupportedException: The invoked member is not supported in a dynamic assembly.
at System.Reflection.Emit.InternalAssemblyBuilder.GetManifestResourceStream(String name)
at FsXaml.InjectXaml.from(String file, Object root)
at FsXaml.App.InitializeComponent() at FsXaml.App..ctor()
at FSI_0002.main[a](a argv) in C:\Users\bobmc\OneDrive\FSharp\Learning\WPFExamples\FsXaml\demos\WpfSimpleMvvmApplication\WPFApp.fsx:line 104
at .$FSI_0002.main@() in C:\Users\bobmc\OneDrive\FSharp\Learning\WPFExamples\FsXaml\demos\WpfSimpleMvvmApplication\WPFApp.fsx:line 109

Can I use the F# interpreter with FsXaml? Thanks to all for your help.

Mikhail Tulubaev
  • 4,141
  • 19
  • 31
Bob McCrory
  • 183
  • 1
  • 3
  • In looking at my code in another context, I can see that the XAML files are referring to each other and to namespaces and types in source files (I think). This all seems incredibly convoluted, and I'm very discouraged. – Bob McCrory Jan 31 '17 at 00:02
  • 3
    Unfortunately, it just doesn't work. (I'm the author of FsXaml...) I tried to explain why in an answer, but its not something I'm happy about. Note that the XAML files referencing each other isn't an issue - that's really what makes FsXaml nice - it's more limitations of WPF itself w.r.t. using it a scripting context. – Reed Copsey Feb 02 '17 at 18:36
  • Reed, thank you for taking the time to answer. I'm trying to build a series of WPF/F# examples of increasing complexity so I can figure out what's going on. It's slow going; the examples on GitHub are too complicated for me to follow at this point. Some day, though. – Bob McCrory Feb 03 '17 at 05:42
  • always happy to help. I'm often on the f# chat here (or fsharp.org slack) if you want to discuss what you're after – Reed Copsey Feb 03 '17 at 05:44

1 Answers1

6

Unfortunately, WPF and scripts don't play well together.

The exception occurs within the WPF runtime itself - FsXaml.InjectXaml is using a XamlObjectWriter to populate the type with the contents from the XAML file. This type doesn't work if you're using a dynamic assembly (like FSI), which unfortunately means that FsXaml will likely never be able to work from FSI.

That being said, even if there was a way around this, it'd be of very limited use. WPF also has restrictions that make it not play well with a scripting scenario, such as the "only one application can ever be created within a given AppDomain" restriction. That one makes it so closing the "main" (first) window makes it so you can never open another one. As such, I haven't prioritized trying to make this work in FSI.

I'd be happy to accept contributions if somebody has an idea of how to make FsXaml play more nicely within the context of FSI, but at this point, I don't see a good solution for that usage scenario.

Edit: FsXaml 3.1.6 now includes functionality to make this a lot easier. It works well, provided you don't close the main window, or you use dialogs. There is a demo application/script illustrating this.

Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
  • I'm using 3.1.6 and still getting this problem with F# Interactive... Is there something specific I need to do besides just initializing a XAML type generated from a Window .xaml? – Rei Miyasaka Feb 24 '19 at 21:24