This is great! I used this yesterday and copy/pasting in the config into the box worked brilliantly. (Selecting the file didn't, but I'm not 100% sure that's not my fault...)

Perfect !

I have not votes left and would love to upvote this. I'm currently working with Couchbase in our project and need to be able to check in a linqpad script that has the connection strings in.

As a side note, there is an official API to handle this when creating app domains, see http://msdn.microsoft.com/en-us/library/system.appdomainsetup.configurationfile(v=vs.110).aspx

Using that API the query properties could have a 3rd tab where you can specify your configuration. Running the query extracts the config to a temporary file.

@Rekna: That's actually a better solution than the current per-query workaround suggested by Joe. But still I'm sure LINQPad itself could store the config in the .linq file, and when it creates the AppDomin prior to running the query, it could extract the config to a temporary file and call .SetData() itself, pointing to the temporary file. That would really streamline this whole config business, and keep everything in one file - the .linq file.

actually, you can do this already, simply by adding the following statement to your query:
AppDomain.CurrentDomain.SetData("APP_CONFIG_FILE", @"C:\Shared\app.config");
Just be sure not to access any config settings before executing the command

This would be enormously useful. My main problem at the moment is that I'm working with a custom assembly that has its own settings, but some of my extensions need settings that exist in linqpad.config (don't ask; I do odd things :P ). It's not possible to read from both; when using the custom assembly as the connection for the query, I get an error stating that the settings don't exist in the config file because it's trying to read them from the assembly's config file and not linqpad.config.

I would rather prefer something like
var settings=Util.Config("c:\mypath\myconfig.config");
which reads an app.config style format and allows me to access (read+write) keys such as
<appSettings>
<add key="mykey" value="myvalue"/>
</appSettings>

I think the way it should be done is by adding another tab to F4 (Query Properties). Just like there's an "Additional References" tab and an "Additional Namespace Imports" tab, there should also be an "Additional Configuration" tab that allows adding more stuff to a virtual per-query app.config, that is saved inside the .linq file together with everything else.

One UI layout would be to split up the tab area into two - a smaller area for adding a <section> element to the <configurationSections> group, and another bigger area for writing the actual configuration section.

Another UI approach would be to have a list of configuration sections in a ListBox on the left, and clicking one would display the XML only for that configuration section. A button to add a configuration section would allow you to specify the name and assembly (or even pick one from referenced assemblies). The would ensure that the <configurationSections> group would always be in sync with the actual configuration sections, and that any assembly needed is referenced properly.

Having a nice XML editing experience in there would be a plus (i.e. syntax highlighting, IntelliSense via XSD, etc), but bare-bones textboxes alone would be a huge help.

where does this app.config belong if I don't use the file copy deal?

thanks for the workaround

Contonuing on from my other comment, if anyone wants to have a go at getting the Dump() working, I get get the "plain text" output happening ok but if I add the description parameter I get an error that "Type 'LINQPad.ObjectGraph.HeadingPresenter' in (...linqpad assembly..) is not marked as serializable".

Just change MyLinqPadClass to:

public class MyLinqPadClass : MarshalByRefObject
{
public MyLinqPadClass(TextWriter writer)
{
Console.SetOut(writer);
}

public void Main()
{
AppDomain.CurrentDomain.FriendlyName.Dump(); // ok
AppDomain.CurrentDomain.FriendlyName.Dump("My description"); // not ok

// Do your stuff within the new domain...
}
}

This suggestion is a good one. I hope it makes it through.

Meanwhile, this is what I use. I had trouble getting Dump() to work in the new domain so I've just used Console.Out

void Main()
{
string[] paths = {
Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location),
System.Environment.CurrentDirectory
};

AppDomainSetup setup = new AppDomainSetup() {
PrivateBinPath = String.Join(";", paths),
ConfigurationFile = @"C:\path\to\my\configfile.config",
ApplicationBase = @"C:\", // because the bin paths must be under the base.
ApplicationTrust = AppDomain.CurrentDomain.ApplicationTrust
};

// Create the new AppDomain
AppDomain appDomain = AppDomain.CreateDomain(
"MyAppDomain",
AppDomain.CurrentDomain.Evidence,
setup);

// Create an object within the new Domain
MyLinqPadClass proxy = (MyLinqPadClass)appDomain.CreateInstanceAndUnwrap(
Assembly.GetExecutingAssembly().FullName,
typeof(MyLinqPadClass).FullName,
false,
0,
null,
new[] { Console.Out},
Thread.CurrentThread.CurrentCulture,
null,
AppDomain.CurrentDomain.Evidence
);


// call the startup method - something like alternative main()
proxy.Main();

// in the end, unload the domain
AppDomain.Unload(appDomain);
}

public class MyLinqPadClass : MarshalByRefObject
{
private readonly TextWriter _writer;

public MyLinqPadClass(TextWriter writer)
{
_writer = writer;
}

public void Main()
{
_writer.WriteLine("Executing within " + AppDomain.CurrentDomain.FriendlyName);

// Do your stuff within the new domain...
}
}

Agreed 110%. This tool is so useful to script calls to application code for batch updates, but a stumbling block I've had is no way (that I am aware of) to attach an arbitrary config file to the AppDomain that the scripts execute under.

Plus you can't add appsettings KeyValuePairs directly in your LinqPad script because the collection is read only.

Unfortunately, I can't convince everybody to parameterize configuration elments in all class methods (instead of using app domain local config binding) just to make it LinqPAD friendly. LOL. =)