REFRESH!

[Minesweeper] 92 Games Played. 64 Bombs Used. 12946 Moves Performed. 18 New Users

Been working on the website again lately. Not quite ready to deploy yet, but I implemented a webhook controller in the API layer that can handle GitHub "push" payloads to automatically process xmldocs on a new tag. I'm getting my evenings back!

[rubberduck-vba/Rubberduck] ateric added label bug to issue #6020: Error on close.

[rubberduck-vba/Rubberduck] ateric opened issue #6020: Error on close.

[rubberduck-vba/Rubberduck] retailcoder closed issue #6020: Error on close.

[rubberduck-vba/Rubberduck] retailcoder created comment on issue #6020: Error on close.

> Indeed, not expected. Crashing on exit has been afflicting Rubberduck for a long time, it's a known and disclosed issue. One solution would be to isolate RD by implementing a COM shim that loads RD into its own appdomain, but that would further complicate an already-complex build process. So what we're looking at is to remove all but one toolwindow, and move the entire RD UI there (including a custom editor pane) - work has begun on that front, but that's Rubberduck 3.x stuff involving a compl

@IvenBach good to see you come out of lurk mode. I don't think there is a strikethrough mode in chat. :(

So guys, I'd like your input on this: I made a private Rubberduck3 repo and started it from scratch, starting with the Rubberduck.Main entry point (IDTExtensility2) and all it does is it initializes a CommandBar menu (with just 2 items: "Rubberduck Editor" and "About") and spawns a dockable toolwindow that contains an AvalonEdit control

There's literally nothing else

I was thinking about making it public / transferring ownership to the org, and setting up a project on the repo to track a clear roadmap for bringing in the features we always dreamed of, but two things make me hesitate

1) losing the commit history

2) doing this incrementally in a separate branch instead might actually be possible

IDK what the better strategy would be, but putting v3 in its own repo does make it much simpler to work on v3 without (further) breaking v2.x

Wow... how long have we talked about AvalonEdit? And you're making it happen?!??!?!! <insert heart emoji here> TBH, everything that's ever been said about it was that it would be such a breaking change and that's why nobody ever pulled the trigger. I think that making a clean break (after all, you've started this in a whole new repo) is the logical way to go.

The RD2 repo could be, essentially, frozen except for bug fixes while any new effort people put in could go into RD3. The only concern for backward compatibility (and commit history) would be keeping the name/logo, and reading the old preferences file.

*reading the old preferences file would be an optional backwards compatibility item. ;)

I've gotta say, @MathieuGuindon, that if this ~2-year hiatus is what it took to get moving on all the wonders and magic that AvalonEdit is supposed to bring, then, in retrospect, it will have been worth it! Though we really missed you.

if RD3 is essentially separate, a new project makes sense. you would be able to link to it on the documentation page on git and move people forward, where both are worked in parallel for some time. losing the commit history doesn't seem as significant a point when you look at making it a clean separation

@MathieuGuindon if you start that from scratch, can you please make sure that it's running against a recent .NET release? Like .NET6 would be great

I've been intermittently fighting with targeting the solution to something newer to get coverage and building via the dotnet cli

Considering that we basically have two complete solutions already integrated in the one repo, I don't really mind adding a third for a RD3.0. That also has the advantage of enabling us to keep commit history for most of the things and easily migrating functionality over to the new solution.

(also where'd you get a working IDTExtensibility2? That's the current blocking issue for building with dotnet over msbuild)

@Duga tbf the crash on exit might still not vanish and I think we don't have a choice on the COM shim anymore, because the current setup does not seem to want to cooperate with modern .NET SDKs and runtimes

Considering that @this has not been around we also don't have anyone that's properly aware of the way registration works (and what the whole RubberduckMeta shenanigans are doing)

@Vogel612 I've targeted 4.8 and the reference to extensibility.dll just worked IIRC. Originally went for .net 6 but couldn't get it to work and thought screw it, 4.8 is LTS and already a better target than 4.6.1... and it builds in VS2022.

it's incredibly annoying that extensibility.dll is not redistributed via nuget, otherwise that would probably be working

yeah

Part of the problem is most likely that the dll is shipped with the MSBuild Shared References and I assume .NET6 projects are built via dotnet and not msbuild ...

what's crazy is that it's just an interface, there should be a way to make our own and make .net think it's the same thing, like Wayne did for the MSForms override stuff

type safety is fun until it isn't :D

not sure how we make the compiler think that it's from the extensibility.dll

so anyway, going with the separate-repo strategy... that does have a couple of implications for the website - for now I'll keep everything pointing to the /Rubberduck repo, but gotta keep in mind that it'll need to become /Rubberduck3 at some point. also since the GD environment doesn't let me define env variables, I've decided to script a config table in rubberduckdb and put the plaintext GH tokens and other secrets in there with an "encrypted" flag that'll flip on after a first read.

that way localdb can have per-dev secrets, and the prod db will be somewhat secure

(so app.config only has a localdb connection string and can be checked-in safely)

^^ RD3 so far :)

nice opportunity to clean things up a bit as stuff gets migrated over

also..

the bottom label can be updated by the initialization code, so if startup starts taking too long at least the user will know what's going on

I think we're going to need a new DI strategy, make some things more lazily loaded

(for now it's pretty much instant, ..because there's pretty much nothing going on)

parser state and command infrastructure are great, the UI for the toolwindows might be better off lazy, but alas

well if there's only 1 toolwindow the VBE needs to be aware of, ...we can lazy-load everything else, no?

yup

also probably makes teardown safer

home page (top part), 80% zoom to fit the download figures

^ fully functional

the feature pages render markdown, and <code></code> tags render as syntax-highlighted code blocks:

standardized feature items (xmldocs) page

xmldoc-generated pages now load all examples so there's no more page load when you pick an example tab

anyway, back to work for now.. I'll come back - promise!

I love the tags on the pages

yeah there's actually a little bug with that :/ they all say it was parsed from the "next" tag even when the item is discontinued and was parsed from "main" (hence the IsDiscontinued flag isn't working either), but it's pretty minor

@MathieuGuindon :+1: on your work Mug.

@IvenBach Thanks!

BTW once I have something that's deployable I'll setup a test.rubberduckvba.com subdomain and deploy there so we can generate the content for all features (I'll migrate whatever data I already have in my localdb first) before the go-live

sounds awesome, but that's a fairly obvious subdomain

gotta put that *.rubberduckvba.com cert to good use =)

So the plan for tonight is to remove the somewhat broken admin/editfeature page and add "edit" links (for authenticated requests only, duh) to the feature boxes and pages it's easy to quickly edit something when we see something that needs editing.

basically just grab the existing stuff and put it in a modal

[rubberduck-vba/Rubberduck] 1646 stars vs. [decalage2/oletools] 2212 stars