mausch / XmlLiteralsTypeProvider

F# type provider implementing compile-time XML literals
Apache License 2.0
5 stars 2 forks source link

Fix Issue #1 Support reading from the file system. #13

Closed panesofglass closed 10 years ago

panesofglass commented 10 years ago

This is a fix for #1. I'm not sure why that doesn't link appropriately in the title.

mausch commented 10 years ago

Thanks, but it's not working for me :-( I get the error: "The type provider 'XmlLiteralsImpl.XmlLiteralsProvider' reported an error: Data at the root level is invalid. Line 1, position 1." To avoid confusions with the string/file source, I put the file template in a separate generated type ( 8954adfe5d5c0f1aa900e0c02bdb4230aab01e99 ), but I'm getting a different error: "A problem occurred writing the binary 'obj\Debug\Tests.exe': Error in pass3 for type Tests, error: Error in pass3 for type tests@46-1, error: Error in GetMethodRefAsMethodDefIdx for mref = ".ctor", error: Exception of type 'Microsoft.FSharp.Compiler.AbstractIL.ILBinaryWriter+MethodDefNotFound'"

panesofglass commented 10 years ago

Did the sample.html include the doctype? If so, that would cause it.

panesofglass commented 10 years ago

I see that my commits included that change. I'm also now getting this error. That's really odd. I wonder if it only worked before I tried using the URI option. I was having a really hard time trying to understand how to debug and test this thing. This is my first rodeo with type providers.

mausch commented 10 years ago

I included now a test.bat to compile everything and run the tests. This also helps avoid the DLL locking.

panesofglass commented 10 years ago

For one thing, I think the use of Uri.AbsolutePath is invalid. That should change to .OriginalString for now.

panesofglass commented 10 years ago

Thanks!

panesofglass commented 10 years ago

If you figure out what is causing that error, please let me know. I realized that I must have been using the version where I essentially did exactly what you are now doing, except that I only generated a single type. I was initially testing whether the string existed as a file.

panesofglass commented 10 years ago

Looks like it works if you generate either one type or the other. You may have discovered a type provider bug. Looks like it is having a hard time with two types that have the same signature.

panesofglass commented 10 years ago

I fixed it by merging the two types. I don't like the current test to determine whether the string is a file path or sample, though.