Ok, got the client proxies covered. Moving as much as possible out of Server LocalDb into Rubberduck.RPC so that Server.LSP pretty much only needs to implement the server commands
Also Server.Telemetry has a number of shared abstractions with Server.LocalDb given the need for a database.
So... my immediate question would be... Should we write the front-end in twinBASIC? Not having to deal with COM interop could save a bajillion memory leaks...
But, is it ready? And what about licensing for x64?
this basically allow twinBASIC to bootstrap .NET Core and use it directly. That eliminates the WinForms entirely, hosting the WPF directly on the tB window.
but honestly, .NET Core can probably just use the usual COM stuff. dscom can be used to provide the type library registration (there's a PR pending). That would then enable RD to run on .NET core and as bonus chuck the olewoo + deployment projects
I'm mostly a .Net developer, and mostly services within that. Which means console apps using GenericHostBuilder. So I'm used to shortcuts like app.AddWPF(). I think you need to get to the point where tB integration is just app.AddTwinBasic()
well, yeah but to do this, I have to start .NET Core, then call into a COM object from the assembly, and then give it the tB window, which is loaded into WPF's hWndSource class and presto, a WPF page displays on tB window.
the other advantage is that tB can be made into an effective shim for the addin & VBE addin, allowing us to control the shutdown.
not that .NET Core needs it because it's already a standalone --- the shim thing was necessary with .NET FX due to the fact that you had to load the mscoree which basically was global to all .NET FX stuff.
@mansellan hello! yes, LSP is happening, and telemetry, and everything we ever dreamed of. It's just a matter of... well, kind of rewriting/porting RD piece by piece to the RD3 paradigm
so no matter what process you're using, you are always going through the mscoree.dll to do the initial setup and it handles the location of the .NET FX assembly, loading it and returning the COM representation from that.
instead of having a mscoree.dll that does the work of setup and returning a COM representation, they now generate a .comhost.dll which has all the code generated to handle all that. In effect, it's now just a normal DLL
no more regasm.exe; you just use regsvr32.exe just like you used to do
anyway back in that project, there's no COM exposure because I don't have to go through that COM activation since I've already bootstrapped the .NET Core so I got a delegate that returns a COM interface.
and tB gets that COM object out, all without any COM registrations at all.
if you look, I also defined the same COM interfaces twice, in tB and again in .NET. They aren't sharing the same definition, proving that tB can use "private" COM interfaces as long it has the correct definitions.
@this and then .net can consume the tB COM library and presto we have a Rubberduck.VBEditor written in tB, and all the VBE interfacing remains in COM land
@MathieuGuindon Yes, that's certainly one way to do it. If we do go down that road, tB can start out as a simple shim, handing out the COM interface to the VBEditor and we can slowly transfer the responibility down to only the managed COM objects.
@mansellan Yes true. will need the license, though to avoid the splash penalty for 64-bit builds. Still not sure how to handle it on AV.
VBA Rubberducking
VBA Rubberducking