REFRESH!

[Minesweeper] 136 Games Played. 82 Bombs Used. 15462 Moves Performed. 12 New Users

[rubberduck-vba/Rubberduck] 5 issue comments

[Rubberduck] 1 Synchronizations

so, good news is I was able to get the solutions building mostly with dotnet build. The bad news is that dSPACE.Runtime.InteropServices nuget doesn't seem to be able to resolve the type library the same way the System.Runtime.InteropServices does. It's not yet clear if it's due to other issues because it was complaining about a missing ref to Windows.Forms v4.0.0.0, similar to what I was fighting earlier with the resources.

My concern is that if it's the same situation with resources, it'll "build" but face-plant at runtime because it's going to look for a FX dependency that dotnet build doens't want to include or something.

They also have a command line tool in addition to the nuget package so I took it and ran it against the MSBuild version and got the same error so this particular error is not likely related to the dotnet build:

PS C:\GitHub\Rubberduck> dscom tlbexport .\Rubberduck.Deployment\bin\Rubberduck.dll --out .\Rubberduck.Deployment\bin\Test.tlb
dscom : warning TX00000000 : Type library exporter encountered an error while processing 'Rubberduck'. Error: Could not load file or assembly 'System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. The system cannot find the file specified.
dscom : warning TX00000000 : Type library exporter encountered an error while processing 'Microsoft.VisualStudio.Interop'. Error: Could not load file or assembly 'Microsoft.VisualStudio.Imaging.…

Opened an issue. We'll see.

Therefore, a dotnet build would end up with 2 DLLs rather than a single DLL and 2 TLBs.

ha, nice gotcha!

makes sense, too

the whole build thing makes me feel like I'm trading a dollar for four quarters. Or maybe 20 nickels.

on the bright side I have a Rubberduck.DataServer app that should be able to read and write to the database and (fingers crossed) receive RPC requests from Rubberduck.Server.

and laptop battery is about drained, which means I should probably leave it for today (if I keep it plugged I'm not going to sleep!)

@this dotnet build across the board is just "nice to have" at this point, no?

well, until msbuild goes EOL, that is

feels so close though

I get you on RE: sleep

RE: dotnet build - Probably yes. It's mostly so that we don't have to depend on a huge framework and issues arising from such monolithic build but it does works.... Kinda.

I think in the end, we'll want to really separate the server (which can be whatever) from the addin code.

heck, the LSP client could be dot net. It's only the addin itself that needs ot be .NET FX for convenience.

hm, perhaps the RD3 repo could end up public as RubberduckLSP or something, and then a (monstrous) PR could hack & slash 2.x into 3.0?

IDK

basically the Rubberduck repo would end up only having the add-in, installer, and COM libraries

Maybe, if we can ensure that the addin part, the LSP client and the LSP server are cleanly separated.

Yeah, that would be one way to do it. Consume the RubberduckLSP as a nuget, maybe.

I already added a Rubberduck.Client project for that :)

to clarify client is what? the addin or the LSP client?

the LSP client

cool

hopefully separating addin and LSP client isn't overkill.... right?

might get folded into a namespace if it is, but I think it's not a wrong separation to have

especially if the LSP client could be .net 6

yes, that's the goal. To minimize the FX into one tiny little silo

it's starting to shape up!

Eating a whale one bite at a time

hopefully we'll hit "done" a little bit earlier than 89 years into it tho

:D

lol. hopefully!

calling it a day. have a good night!

gn!

@MathieuGuindon coverage kinda sorta maybe depends on it, except there might be better alternatives to Opencover

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot created comment on pull request #6076: DirectoryNotFoundExpection on new development system fixes #6072

> :x: Build Rubberduck 2.5.2.6236 failed (commit github.com/rubberduck-vba/Rubberduck/commit/eff1939ec8 by @INOPIAE)

[rubberduck-vba/Rubberduck] build for commit d10525f4 on unknown branch: AppVeyor build failed

BUILD FAILURE!

@Feeds so, how does one read a textbook that's made of lithium or beryllium, then?

not near octium, that would be annoyingly reactive

[rubberduck-vba/Rubberduck] DjXarlos starred us

FWIW, got it to build w/ dSPACE with some modifications, need testing