It's a huge project. Most of the work has been in bringing the current experience to .NET Core. For example, being able to reference a .NET Core library - and have its dependencies resolve correctly - is a non-trivial task that consumed some weeks. The removal of AppDomains, in most cases, means spinning up separate processes for isolation, and communicating with those processes cannot be done with Remoting, because that's gone, too.
I've also had to re-write the back-end for the NuGet package manager. The good news is that it's now faster because it loads assemblies directly from the local user package cache. It also now able to properly handle native dependencies using .NET Core's convention-based protocol and the new AssemblyLoadContext.
The DataContext driver model has also been revamped so that you can write and deploy third-party drivers just by publishing a NuGet package.
I'm hoping to release a preview in June - will keep you posted.
@JoeAlbahari will there be any new support for sharing linqpad code between scripts? The "My Extensions" ends up being so big because of how much I share there, and publishing a nuget package for sharing is so heavyweight.
If there isn't/can't be some kind of #include-ish thing, could it support partial classes for My Extensions? Even being able to break My Extensions up among multiple files would make it a lot easier and simpler to use it as a code sharing mechanism, but still have the same dll/pdb output as the single-file My Extensions does today.
Just a thought. Certainly being able to #include or something like it specific scripts would be wonderful!
With LINQPad 6, right now I'm concentrating on feature parity.
An #include option, or the ability to reference one query from another is unlikely to happen unless I can figure out at least how to resolve all the problem it will create from a users perspective. The ability to separate My Extensions into multiple files, however, is something that could work.
I use this for several projects (each with own set of extensions) and it works fine. You can open the correct instance by dragging and dropping the LINQ file on the executable.
@nescafe I do this now, and it works, but some of those projects still have large (many lines of code) sets of shared code in their My Extensions that I'd like to split up among multiple files (POCO classes for tons of API calls, for example).
If My Extensions just changed from being a single file to a folder (so more analogous to plugins) then I could split functionality up over multiple files more easily.
In an ideal world I'd like to be able to hit F4 and 'add reference' to shared functionality that's sitting in a .linq file instead of a .dll, but some mechanism to split My Extensions up among multiple files works at least in terms of getting a bit better maintainability and avoiding a huge single file.
LINQPad 6 will be .NET Core only. It would massively bloat its complexity if it had to support both .NET Core and .NET Framework, given the significant runtime. However, you'll be a be able to run LINQPad 5 side-by-side to support .NET Framework, and there will still be updates to LINQPad 5 - in particular, for compatibility with the enhanced driver model, and some feature/performance improvements.
Comments
I've also had to re-write the back-end for the NuGet package manager. The good news is that it's now faster because it loads assemblies directly from the local user package cache. It also now able to properly handle native dependencies using .NET Core's convention-based protocol and the new AssemblyLoadContext.
The DataContext driver model has also been revamped so that you can write and deploy third-party drivers just by publishing a NuGet package.
I'm hoping to release a preview in June - will keep you posted.
If there isn't/can't be some kind of #include-ish thing, could it support partial classes for My Extensions? Even being able to break My Extensions up among multiple files would make it a lot easier and simpler to use it as a code sharing mechanism, but still have the same dll/pdb output as the single-file My Extensions does today.
Just a thought. Certainly being able to #include or something like it specific scripts would be wonderful!
Looking forward to LINQPad 6!
An #include option, or the ability to reference one query from another is unlikely to happen unless I can figure out at least how to resolve all the problem it will create from a users perspective. The ability to separate My Extensions into multiple files, however, is something that could work.
I use this for several projects (each with own set of extensions) and it works fine. You can open the correct instance by dragging and dropping the LINQ file on the executable.
If My Extensions just changed from being a single file to a folder (so more analogous to plugins) then I could split functionality up over multiple files more easily.
In an ideal world I'd like to be able to hit F4 and 'add reference' to shared functionality that's sitting in a .linq file instead of a .dll, but some mechanism to split My Extensions up among multiple files works at least in terms of getting a bit better maintainability and avoiding a huge single file.
forum.linqpad.net/discussion/1877/linqpad-6-for-net-core-3-preview-now-available