Script extensions

[jwallet]

I would like to introduce the feature extensions to NetPad like LinqPad does:
https://www.syncfusion.com/succinctly-free-ebooks/getting-the-most-from-linqpad-succinctly/linqpad-extensibility

Were you already working on it, or planning to add it when you mentioned in your road map "Referencing other scripts" ?
Is it something for NetPad? I did not look at all the code yet, but I was thinking about doing pretty much the same thing as LinqPad add provide an extension file that will be injected with the rest of the code aswell as being injected to OmniSharp

[tareqimbasher]

Definitely something I want to add, and even though its not on the README roadmap, I have it as a ticket on my, private, GitHub project that I use to track all the features I want to add which are too long to add to the README.

For "Referencing other scripts" I meant a feature similar to the #load directive in LINQPad where you can reference other scripts but both features are similar in certain ways. Both of them are on the radar, albeit the former isn't on the README.

I was debating naming the file something like "Common" or "Shared" vs "My Extensions" as users can really add any common code there, not just extension methods.

Another point to think about, is what if we make the "Common/Shared/My Extensions/" a folder, instead of a single file, where all scripts in that folder get included in all scripts.

Yet a third point to mull on (while this example assumes we do a folder instead of a file, we still need to determine the best route even if we just do a common file): We'd need to determine how we'd handle 2 different common scripts referencing 2 different versions of the same NuGet package. Example: CommonScriptA references Newtonsoft.Json v11 while CommonScriptB references Newtonsoft.Json v12, which version should be used in the main script the user is working on? The lower version, or the higher one? Also what if the main script also references Newtonsoft.Json v13 for example, do we use the lower/higher of the 3, or does the version referenced in the main script win in this case? Should that decision be controlled by a script-specific config setting?

[jwallet]

I really like your concept and having a folder. It sounds great for a final version but maybe we can deliver a initial version that handles common code in just one file so we dont need to handle right now multi versions, so just a v1 that delivers the bare minimum but we implement it with the final version in mind

Also the compilation/ build process that occurs every time we hit play script, is pretty slow right now. With this new feature it will just get worst. So I think we will need a task that runs in the background to keep compiling in memory so it start the script right away, as well as keeping Omnisharp updated with our common extensions to have the intellisense always ready to display our custom code in a script. What are your thoughts ?

[tareqimbasher]

Sure we can do a single file initially and build it with the expansion to multiple files in mind. We'd still need to resolve the problem I stated about dependency version conflicts even with a single file, unless the initial version won't include the ability to add dependencies to it at all.

I would like to explore your second point further. The build process the first time you run a script, particularly when it has a data connection assigned can be a bit slow, but should be pretty quick on subsequent runs. I'm looking into why the first run is slow but its mostly taking time confirming the required NuGet packages are installed and checking dependencies, and not so much compiling. This is at least my experience and what I'm seeing, are you seeing that running a script takes a long time every single time you run it? And if so, do you see that slow down on every run for scripts with data connections only or with any script?

[jwallet]

Yes the version conflicts will be a pain I guess.

About the second topic. I'm not using the data connection dropdown I'm actually using my project dll to get my appdbcontext with my database connection string (using the coded provided in the other github question here). So I know it's jot conventional because it creates it everytime I run my script and that's why it takes 4000ms to reach my first getbyid query on my Macbook Pro Intel. However I think if we can have a file that lets you create extensions like getting a dbcontext and we can have it kept on memory so it does not get disposed everytime the script ends, it will be time saving and the stopwatch at the bottom left will be accurate to what we want to test because all the setup code will live in another file and the script file will be ready to use at line 1.