Hm, the updater app could be started by RD just like the LSP server, and then when it pops a notification about a new version available it could send the exit notifications and perform the server updates in the background while sending WorkDoneProgress notifications to the RD add-in client!
with the RPC infra already in place, that would be pretty simple actually
The macro below loops through column E in Sheet2 and finds matches in column Z of Sheet1. If a match is found it copies the value on the same row contained in column AA.
It works ok but hangs when it runs. There are usually a few thousand values in column E but less than 30 in column Z.
I've run ...
It's nice seeing the compile errors move to the outer layers and into the entry points and add-in client view models... sign that the struggle is coming to an end, there's light at the end of the tunnel!
I'm moving Rubberduck.InternalApi.LSP into the Rubberduck.RPC assembly, where everything is nicely organized into clear namespaces and folders. It belongs there because it makes no sense to have the LSP model split up into "purely LSP" and "LSP but just the bits shared between RPC servers"
we have InternalAPI because we wanted to avoid duplicating the code and also to avoid weird dependency graph. Does the RPC need to be still a separate assembly from the InternalAPI?
at first I added .RPC to separate the server-side stuff from the rest of the internal API.. didn't feel right to have any of it there. I think InternalApi is going to end up with a bunch of extension methods, common Model classes (that's where QMNs and Selection lives now)
@MathieuGuindon Ok, didn't think so. I asked because i'm at a crossroads. Do I want to finish the tB addin replacement or do I want get the DSCOM working....
pros for tb Addin: no more complex registration logic needed and we get complete control over the .NET hosting and therefore disconnection. Bye bye WinForm. Bye bye hacks to make WinForm work in VBE. Con: still a untested technology relative to C# add-in.
pros for dscom registration: registration logic is simplified. probably won't need Deployment.Build but still need Deployment project. Con: still stuck with winform wrapping WPF and using the hacks to handle disconnection.
yes we do have 32/64 bit version but they're one same library
I was thinking we had a separate type library for the extension and for the unit testing stuff but I was mistaken. They are all in one big type library.
a tB addin would mean that the unit testing stuff would no longer be in that library because they would not be changed. We'd end up with two type libraries; one for the extension which is hosted by the new tB addin, and another to define all unit testing & fakes stuff
one thing is that if it's using .NET rather than .NET FX, we'll have Rubberduck.comhost.dll which can be only 32-bit or 64-bit -- we'd need to build both DLLs because .NET core does not support Any CPU for COM host DLL.
or, we go forward with the RD updater app, and let the app determine what version of Office is installed on the user's machine and pick the correct RD installer build?
VBA Rubberducking
VBA Rubberducking