Fix type provider to use new SDK

[ReedCopsey]

I merged @dsyme 's PR #72 in order to try to make this work against the new SDK -

However, it's failing, and currently not in a working state. Everything builds, but at runtime, the type provider is unusable, with an error stating: "The method or operation is not implemented."

It also appears that the attributes which cause the types to not be sealed (required for FsXaml) are not being honored properly.

I'm going to try to see if I can figure out what happened in the port - but I wanted to open an issue to document as I try to move the progress forward with this.

[ReedCopsey]

@dsyme So - I've narrowed down the problem: It appears that the behavior of constructors has changed.

When trying to add the code within the constructor to call the InitializeComponent () method (also defined within the type), the updated version fails with: "The method or operation is not implemented."

I'm not sure exactly why this is occurring - so I'd appreciate it if you took a look.

This issue occurs on this line: https://github.com/fsprojects/FsXaml/blob/master/src/FsXaml.Wpf.TypeProvider/XamlTypeUtils.fs#L100

I switched around the build to make it slightly easier for you to debug. If you build in debug, then open the FsXaml.Demos.sln solution (in root) in another VS instance, it'll pick up the debug assemblies and let you see the error directly. Opening the demos solution is the easiest way to confirm proper operation - it really hits all of the functionality, and won't build if the type provider is not implementing the proper operations.

[dsyme]

@ReedCopsey I've found a few more issues, will submit an update to the SDK soon

[dsyme]

@ReedCopsey The SDK is now updated with fixes that could have plausibly caused this. If you have time could you run paket update and submit another PR to try again? Thanks

[ReedCopsey]

@dsyme New error occurs now:

Type mismatch when building 'value': the type of the field was incorrect. Expected 'System.Boolean', but received type 'ctxt type System.Boolean'.

This occurs with various types throughout the type provider demo project, and causes each type to fail. I've pushed the updated version using the latest SDK, so feel free to grab the latest to repro.

(Note that the push includes fsprojects/FSharp.TypeProviders.SDK#145 fixed locally, in order to get it to compile.)

[ReedCopsey]

@dsyme After more investigating - it's still a problem with the provided constructor.

The first exception that's raised while debugging is an index out of range exception on line 6284 of ProvidedTypes.fs. sigptr is 82, but the byte[] is length 82.

When walking back the stack trace, this happens inside of the invoke code for the constructor. I've noticed something odd, though (it may just be a debugger issue, but just in case..) the this parameter seems to be grabbing a provided method, not the type itself:

Just in case that helps narrow it down. Originally, the error was slightly different -so I moved the call to add the methods to the type before the contructor was called, which was when I noticed this.

[dsyme]

Thanks, have it on my list to look into

[dsyme]

I believe this issue is now fixed, see fsprojects/FSharp.TypeProviders.SDK#146

[dsyme]

@ReedCopsey Please try the next TPSDK update, thanks

[ReedCopsey]

@dsyme Made some progress, but a similar error still:

Microsoft.FSharp.Compiler.TypeProviderError: 'Type mismatch when building 'args': invalid parameter for a method or indexer property. Expected 'System.Windows.FrameworkElement', but received type 'ctxt type System.Windows.Window'.
Parameter name: receivedType'

(Note that System.Windows.Window is a subclass of FrameworkElement)

[jchidley]

I just cloned a fresh copy of FsXaml and build.cmd failed

     3>C:\Users\jackc\Documents\FsXaml\paket-files\build\fsprojects\FSharp.Type
       Providers.StarterPack\src\ProvidedTypes.fs(3100,16): error FS0039: The v
       alue or constructor 'isNull' is not defined. Maybe you want one of the f
       ollowing:�   DBNull [C:\Users\jackc\Documents\FsXaml\src\FsXaml.Wpf.Type
       Provider\FsXaml.Wpf.TypeProvider.fsproj]
     3>Done Building Project "C:\Users\jackc\Documents\FsXaml\src\FsXaml.Wpf.Ty
       peProvider\FsXaml.Wpf.TypeProvider.fsproj" (Rebuild target(s)) -- FAILED
       .
     1>Done Building Project "C:\Users\jackc\Documents\FsXaml\FsXaml.sln" (Rebu
       ild target(s)) -- FAILED.

Build FAILED.

[ReedCopsey]

@jchidley This is expected until the new TP SDK is corrected.

@dsyme Any ideas on what might be causing this issue?

[ReedCopsey]

@dsyme So - with your latest PR (#150 - fsprojects/FSharp.TypeProviders.SDK#150 ), things are moving forward.

The type provider builds correctly, and no longer gives intellisense errors.

However, at build time, new errors are occuring. They appear to be related to the constructor of the main Window types - I suspect it has to do with the fact that the constructor calls provided methods.

An example of the exact error set is:

1>output error FS0073: error : One of your modules expects the type 'Views.MainWindowBase' to be defined within the module being emitted. You may be missing an input file
1>output error FS0073: error : One of your modules expects the type 'Views.MainWindowBase' to be defined within the module being emitted. You may be missing an input file
1>FSC: error FS2014: A problem occurred writing the binary 'C:\Users\Reed\Documents\GitHub\FsXaml\demos\WpfMvvmAgent\obj\Debug\WpfMvvmAgent.exe': Error in pass3 for type Views.MainWindow, error: Error in GetMethodRefAsMethodDefIdx for mref = (".ctor", "Views.MainWindowBase"), error: Exception of type 'Microsoft.FSharp.Compiler.AbstractIL.ILBinaryWriter+MethodDefNotFound' was thrown.

Note that the code calling this is like the following:

type MainWindowBase = XAML<"MainWindow.xaml">

// This is to demonstrate being able to add in "code behind"
type MainWindow() =
    inherit MainWindowBase()
   // ... more stuff here to override and handle events

[ReedCopsey]

I've pushed this - if you want to repro, just pull, build FsXaml.sln in debug, then open the FsXaml.Demos.sln and try to build.

[ReedCopsey]

@dsyme I tried updating today, with hope that some of the fixes for swagger would help, but the behavior is identical to above.