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.

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.

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.

My suggestion is to add an optional expandable text input pane where any string could be written. This pane would be visible when choosing C# Program (or VB / F# Program) in the language drop down. The program template would then feature a Main(string arg) where the input would be fed.

Many times I find myself pasting json, xml, csv, tsv data etc into the programming pane of linqpad. Afterwards I have to put the text into a string variable and replace quoute characters and other special chars to make it compile. Sometimes I instead write the text into a file and load the file into the variable. Both solutions work and are not to hard to acheive, however it would be quicker just to paste the text into a textbox and have it readily available in the program for processing.

For me this would be a productivity feature I would use quite a lot.

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 sys_extract_utc(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