I see that the My Extensions can also have an App.config. However, I notice that if I make any changes in the F4 > App.config, that they don't take effect unless I close and re-open LinqPad.
Yes, that's probably a bug. The "My Extensions" query is not supposed to support app.config, so that tab should really be disabled.
The problem is that any config settings - even if they work when you test your extensions by running the Main method in My Extensions - will not be reliably picked up in the queries themselves.
RE: "The problem is that any config settings ... - will not be reliably picked up in the queries themselves."
Would you please elaborate on that? Are you saying that My Extensions should not even ever reference AppSettings?
I guess I have problems with that (and disabling appsettings tab). LinqPad is great as a 'scratch pad', but we're also using it as a 'scripting' tool to replace VBS, batch files, PowerShell, etc. In that regards, having just My Extensions is somewhat lacking:
1) it provides us some level of "modularization" so that shared/common "business" classes can be put in one place. (One would certainly argue that "business" classes should not be there, but again, we are using it as a "scripting" tool).
2) Exceptions in My Extensions don't get stopped there, so debugging is difficult.
3) we are forced to create a Main in My Exceptions just to debug.
4) our "business" classes can each use 5 - 10 AppSettings. As used as a scripting tool, we rely on AppSettings for the configuration information. We have 50+ 'main' programs that use the common classes. It's not practical / pretty for each of these main programs to get all the settings and pass them in as parameters (or constructor properties). E.g. any change to the business class requiring additional setting means having to change 50+ programs.
I know that our custom classes can be compiled as assemblies, and included in LinqPad and used by our scripts, but the point of us using LinqPad is the have that script-like experience of not having to go through compile/deploy steps.
I guess one request here is to have an ability to "include" other Query modules as part of a Program.
Comments
The problem is that any config settings - even if they work when you test your extensions by running the Main method in My Extensions - will not be reliably picked up in the queries themselves.
Would you please elaborate on that? Are you saying that My Extensions should not even ever reference AppSettings?
I guess I have problems with that (and disabling appsettings tab). LinqPad is great as a 'scratch pad', but we're also using it as a 'scripting' tool to replace VBS, batch files, PowerShell, etc. In that regards, having just My Extensions is somewhat lacking:
1) it provides us some level of "modularization" so that shared/common "business" classes can be put in one place. (One would certainly argue that "business" classes should not be there, but again, we are using it as a "scripting" tool).
2) Exceptions in My Extensions don't get stopped there, so debugging is difficult.
3) we are forced to create a Main in My Exceptions just to debug.
4) our "business" classes can each use 5 - 10 AppSettings. As used as a scripting tool, we rely on AppSettings for the configuration information. We have 50+ 'main' programs that use the common classes. It's not practical / pretty for each of these main programs to get all the settings and pass them in as parameters (or constructor properties). E.g. any change to the business class requiring additional setting means having to change 50+ programs.
I know that our custom classes can be compiled as assemblies, and included in LinqPad and used by our scripts, but the point of us using LinqPad is the have that script-like experience of not having to go through compile/deploy steps.
I guess one request here is to have an ability to "include" other Query modules as part of a Program.