This would be really handy - I often have one script that creates a file by serializing and one that reads the file by deserializing . At the momen I have to include the types in both scripts and make sure I keep them in Sync. Of course I could create a class library and reference it, but for one off scripts it would be much more convenient to include the types in both scripts via a source include.

Something else that could potentially work pretty easily would be to support having an Extensions.linq query in every folder. It would get included the exact same way that MyExtensions.linq gets included. It provides an easy way to separate out code and it doesn't require adding additional support for #include statements.

well you could make a new namespace and add it there
then get it when needed

In thinking about a cheap and easy way to implement this, I came up with automating the manual way I do this in one set of queries. I have a base statement query that sets up all my data variables. I copy and paste that in the top of each of my real queries that share the base data.

If LINQPad could automate the import, by finding a //#include query comment and then searching for the next //#end-include or //#include, and if it doesn't find //#end-include, insert the file contents after the include, and then insert //#end-include, and if it does find //#end-include, delete the lines after include and insert the file contents in-between.

Better still, add support for #region in statement mode and use #region include query and #endregion query and automatically close the query.

It could do this on opening a query, or a minor optimization, timestamp the end marker and compare to the include query end marker.

The inserted file would have any //#include or #region include modified to not work to prevent nesting issues. If you do nest, you would only get the latest update one level deep, so you'd have to update any include queries by opening and saving them as necessary.

I think this gets around most all of the issues I see with the rest of LINQPad, and yet still provides enough of the value of inclusion to be worthwhile.

I believe that referencing linqpad files makes more sense that cs files, e.g.
#include MySettings.linq
#include MyDTOs.linq

This is never going to be done.

Perhaps what we need to do, is ask Joe ... "How much?" and we start a kickstarter campaign to make it happen?

:)

Happy to pay an extra licence for being able to use this at work across multiple scripts. That would ensure that random kiddy developers who are using Linqpad for playing with coding don't use the mutli-script version and only serious teams would purchase the team-support upgrade.

cmon, let's make this happen!

I have wanted to go beyond the "My Extensions" and found a work around to this issue by creating a LINQPad script that lets you choose another LINQPad script to compile into an assembly, if anyone is interested. You have to format the query a specific way, but it's better than nothing.

As Erling mentioned, would it be easier to just compile the referenced query and add it as a reference behind the scenes somewhere? Just add 'using static MyQueries.QueryName' on the references tab or something. This would import all static members and types, which would achieve the same thing. I know Joe Albahari has mentioned there are plenty of complicated issues with a C style #include, but for the most part I just want this to get at types I can reuse across queries.

+1 csx #load support

I think I have missed this facility frequently. I would like to include a class from my solution so I can quickly test it. Or write new code with correct separation so it can be directly pasted or exported for including in a visual studio solution.
Also I would like to add resources to a LINQ file, like xml, json etc.

Compile MyClass to a dll and reference that ?

I think an export to Visual Studio might be better. Most of my projects start out as LinqPad scripts, then I get too many classes in one .linq file and then have to create a VS project and copy / paste the code, and sort out nuget packages / dependencies.

#include "myotherscript.linq"
Good idear ! That's what I need.

Id rather include another .linq file instead of a .cs, that way if the referenced file was in program format, then the main for the included file will be ingnored, and I could use the main (of the included linq) file, as a means of running some simple tests when working on the script.To edit the included file, I'd simply double click it, and make changes, run some code as a test, and hit save, bosh...done.

c# is boring. better make support for #include MyModule.fs

I just hit a brick wall trying to use linqpad instead of powershell and nant as a built tool, and need to be able to either pass DTO's to a script, (assuming the DTO is in a referenced assembly), or I need to be able to include a script, so that I don't have to repeat myself. With this feature I could use linqpad as a build tool, currently as it stands, I cannot use it for any resonable size project. I could replace powershell, Ruby, Nant ... all with Linqpad, please please please add this feature! ;-D (Util.Run is a good start, but is buggy. Include makes far more sense, alternatively be able to pass proper objects between scripts, so that we don't have to parse strings to objects all the time in Main(string[] args). Linqpad is soooo close to being able to be more useful that powershell!

This is an excellent idea but the implementation would be even cooler if one could reference stand-alone source files just like one can add references to assemblies and NuGet packages. The reference should be in the form of a URL (which could use the file scheme for local files and http/https for remote ones) so one can reference files directly out on the web and they get downloaded and become part of the current query. As long as a source file can be identified by a URL (thinking gists here especially), it should be reference-able. The remote files should be cached in the .linq file when saved for being able to run offline too. Finally, there would be a dialog box that allows one to manage those references and download updates! The cherry on top of all this would be support for NuGet packages that contain source files as content!

Been too long to have the "include" option available...
If it's done via adding one more tab to the "query properties" dialog (F4) it does not seem to hard to be done... ?what's holding back this feature???

I'll suggest also to have 2 panes,,, one for pre-inclusion and one for pós-inclusion...

ZEE

I agree, as fantastic as LINQPad is, this is a significant feature lacking.... within 3 days of purchasing a full license copy I'm Googleing for how to do this exactly.... link to libs or re-usable classes would be far more useful than the MyExtensions.linq file that isn't even stored with all of the other Queries so it's pretty useless to rely on this in Code snippets that ARE shared...

A simple syntax or GUI as others have mentioned, would be Awesome.

#Include ../MyQueryLibs/LINQ2Xml.cs (or .linq if required)....

It would be neat if we could "import" other tabs. Or if something like Program or Statement tabs were always on-the-fly compiled into referenceable dlls that we could import with a linqpad namespace.