The UniversalStaticDriver class does not detect the properties of the customType parameter that are directly of type IEnumerable<T>. If the customType inherits IEnumerable<T> (like say via IList<T>) then the property is detected. But if the property is actually declared as IEnumerable<T> then it is passed over.

I changed the line that declared ienumerableOfT from:

            let ienumerableOfT = prop.PropertyType.GetInterface ("System.Collections.Generic.IEnumerable`1")
            where ienumerableOfT != null

to

            let ienumerableOfT = (prop.PropertyType.GetGenericTypeDefinition() == typeof(IEnumerable<>) ? prop.PropertyType : null)
                                ?? prop.PropertyType.GetInterface("System.Collections.Generic.IEnumerable`1") 

Kinda hacky, but it fixed the problem for me. Probably a better solution would be to recurse through the type and all inherited types till an IEnumerable<T> is found.

The menu item for "Copy for Markdown/Stack Overflow" ends up copying code that in most cases won't compile without manual intervention by the person who grabs it off of Stack Overflow.

Specifically, these two things is on the query options tab, and has to be manually added for the query code to compile and execute:

• References
• Using directives

It would be nice if those two things could be copied alongside the query code, for instance as specially crafted comments at the top, that would be recognized by LINQPad upon pasting back into it, and moved to the appropriate places.

ie.

// reference: <RuntimeDirectory>System.Runtime.Numerics

using System.Runtime.Numerics;

When the code fragment is selected and then F5 is pressed, LINQPad runs only selected code. I think this feature is nice.
When I choose "C# Program" mode, of course I write some utility codes outside the Main() method.
However, when I select the fragment of code in the Main() and press F5, the build fails, since the definitions outside the Main() wasn't included as "compile target codes".

I think that the codes outside Main() method (in C# / VB Program mode) should be always included in compile targets to enable user-defined classes and methods,
even if the code fragment is selected in the editor.

Linqpad doesn't work very well if the underlying columns in an Oracle database contain TIMESTAMP WITH TIME ZONE columns.

These appear in the datacontext as DateTime (losing the offset information), however queries using equality checks against them can fail due to the way the underlying IQDriver handles (or otherwise) the conversion back to datetime offset within Oracle.

It's a bit of a pain, but one of the simple approaches is to ensure the generated SQL wraps those columns in either sysextractutc(theColumn) or 'theColumn AT TIME ZONE xxxx' to ensure they are compared with the DateTime parameter that is bound to the query.

Obviously the better solution would be to implement them 'properly' (map to / from DateTimeOffset), but that might be more complicated

The FSharp compiler macro 'SOURCE_DIRECTORY' doesn't seem to behave as expected in linqpad - specifically it points to a linqpad temporary execution directory, and not where the .linq file itself resides.

This makes it problematic to use F# type providers within linqpad. Referring to data files relative to the script is pretty common, but the path supplied to a type provider has to be a compile-time literal - ie Util.CurrentQueryPath can't be used. Absolute paths obviously break across machines.

Not sure if a fix even is possible (I can't see anywhere on the F# compiler where you can control this behavior) but thought I'd better note it for posterity.