VBA Rubberducking

Duga

00:07

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot prereleased draft prerelease Prerelease-v2.5.2.6215

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot created draft prerelease Prerelease-v2.5.2.6215

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot published prerelease Prerelease-v2.5.2.6215

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot created tag Prerelease-v2.5.2.6215

[rubberduck-vba/Rubberduck] build for commit 095fa86b on next: AppVeyor build succeeded

REFRESH!

[rubberduck-vba/Rubberduck] build for commit 095fa86b on next: 97.58% (target 0.00%)

[Minesweeper] 90 Games Played. 58 Bombs Used. 12840 Moves Performed. 8 New Users

[rubberduck-vba/Rubberduck] 6 additions. 6 deletions. 2 commits. 18 issue comments

[Rubberduck] 1 Indenter requests. 1 Synchronizations

[rubberduck-vba/Rubberduck] pflugs30 created comment on pull request #6063: Fixing various build issues in VS2022 (64-bit)

> Okay, well THAT change didn't work. Something about this build process is still running in 32-bit mode. Guess I'll have to do more investigation into the Appveyor process, or I need to figure out how the build process works locally (or both).

[rubberduck-vba/Rubberduck] retailcoder created comment on pull request #6063: Fixing various build issues in VS2022 (64-bit)

> No wait, I think that one's the token. It failed trying to push a comment on the PR. I just merged the updated token, is this branch up-to-date?

[rubberduck-vba/Rubberduck] pflugs30 created comment on pull request #6063: Fixing various build issues in VS2022 (64-bit)

> Yes, I branched yesterday from next. Should be up to date. We may have multiple failures.

Duga

01:12

[rubberduck-vba/Rubberduck] retailcoder created comment on pull request #6063: Fixing various build issues in VS2022 (64-bit)

> Yeah next has the correct token as of a couple of minutes/hours ago 🤖

Duga

01:35

[rubberduck-vba/Rubberduck] bclothier synchronized pull request #6063: Fixing various build issues in VS2022 (64-bit)

[rubberduck-vba/Rubberduck] bclothier created comment on issue #5961: Building RD fails on olewoo

> Unfortunately, no because the whole idea was to avoid restricting potential contributors to a specific VS version that they may not have. Which was actually the original impetus for this whole goldrube machine.

Anyway, can you confirm if the changes made to the PR enable you to build on VS 2022 with 64-bit MSBuild?

[rubberduck-vba/Rubberduck] bclothier created comment on pull request #6063: Fixing various build issues in VS2022 (64-bit)

> Please don't merge until confirmed that this builds OK on VS 2022 64-bit. It did build OK on VS 2019 32-bit but that's only half of the equation.

Duga

01:59

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot created comment on pull request #6063: Fixing various build issues in VS2022 (64-bit)

> :x: Build Rubberduck 2.5.2.6216 failed (commit github.com/rubberduck-vba/Rubberduck/commit/a8c33382a0 by @bclothier)

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

BUILD FAILURE!

[rubberduck-vba/Rubberduck] bclothier commented on RubberduckTests/Symbols/SelectedDeclarationProviderTests.cs of pull request #6063: Fixing various build issues in VS2022 (64-bit)

[rubberduck-vba/Rubberduck] bclothier synchronized pull request #6063: Fixing various build issues in VS2022 (64-bit)

Duga

02:23

[rubberduck-vba/Rubberduck] Vogel612 created comment on pull request #6063: Fixing various build issues in VS2022 (64-bit)

> This PR replaces #5982 (by completely subsuming it)

Vogel612

@MathieuGuindon lol :)

I must admit that I'm not too happy about the fact that you need to update that token manually regularly (and that you're currently the only one capable of doing so)

Mathieu Guindon

Aye, I should be able to come up with something on the website/API, building a PR could trigger a token check, and the bot account could make a PR to update the .yml, ..and possibly even merge it.

The part about encrypting the token through AppVeyor is another layer though

Vogel612

that seems complicated... can't you just generate a token with longer validity?

Mathieu Guindon

I could make it never expire lol

Vogel612

I know that the tokens that I generated did that

Mathieu Guindon

02:36

Aaah I'd have to log in as the bot again

Yeah I'll fix that

Duga

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot created comment on pull request #6063: Fixing various build issues in VS2022 (64-bit)

> :x: Build Rubberduck 2.5.2.6217 failed (commit github.com/rubberduck-vba/Rubberduck/commit/dee6c51933 by @bclothier)

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

BUILD FAILURE!

Vogel612

Main solution tests are working correctly

Mathieu Guindon

I don't think it'll get RD to work on Win11, could it?

Vogel612

that's "just" the tests for the analyzer project. Seems like the IO mocking layer we're using barfed all over the strong naming

@MathieuGuindon does win11 support 32bit?

this

O joy.

@Vogel612 should. I'm aware of others running 32-bit apps on 11

Mathieu Guindon

02:40

I have to comment out stuff in the dockable presenter ctor to get it to run... Works for inspections and stuff, not so much for screenshots

Could be just me though

this

FWIW, it's not just AppVeyor. It fails on my local machine so that's on me for not running the meta tests.

Vogel612

well, it's closing in on 4AM around these parts, so I'll head to bed... In case I don't get around to checking in here: Good riddance to 2022 and a happy new year :D

this

Happy new year to you as well!

Mathieu Guindon

I installed Community 2019 to work on 2.x

Happy new year!!

@this happy to see you around here lately, what have you been up to? Do you think tB can play a part in the server-side?

this

yeah life & work got in the way for most of the year.

Mathieu Guindon

02:46

same =)

this

what I'm hoping is that it'll be the "com shim" solution we've been looking since it's unmanaged and thus we have more control over the lifecycles so I can see using it to provide information about the VBA project without passing around COM objects

Interesting. Updated all the nuget packages in the meta test projects. Went from 71 failing tests to 0 tests run, 71 tests skipped.

Mathieu Guindon

03:09

sorry I'm half-here, making star wars paper models with the kids, so far we got 6 or 7 made... Starting the imperial star destroyer now

so anyway I went through the LSP specs linked above, and it shouldn't be too hard to implement tbh

Duga

04:56

[rubberduck-vba/Rubberduck] bclothier synchronized pull request #6063: Fixing various build issues in VS2022 (64-bit)

Duga

05:23

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot created comment on pull request #6063: Fixing various build issues in VS2022 (64-bit)

> :white_check_mark: Build Rubberduck 2.5.2.6218 completed (commit github.com/rubberduck-vba/Rubberduck/commit/ca92523158 by @bclothier)

[rubberduck-vba/Rubberduck] build for commit 7be08c19 on unknown branch: AppVeyor build succeeded

Greedo

08:50

2 quick case studies: my python editor Spyder expects language servers to be python programmes which it can launch in the normal way, passing in the port and ip address as command line flags/parameters at startup so it can connect to the server. It can also connect to running python servers written in other languages but does not know how to launch them so cannot control their lifetime, breaking compliance

VSCode is more complicated. Every language server must also define a corresponding client which is a small vscode extension that launches the server. The server can be written in any language since the client is specific to that server so can be designed to launch it in any way. The issue is the client half must be written in JS/TS which is I think less in the language agnostic spirit of LSP

A random idea would be you can use COM both to communicate the LSP messages across processes and to manage the lifetime of the server. This is not an approach I've seen in use though. Would be fully language agnostic though whilst specifying a standard way to launch and kill the server process...

Duga

16:21

[rubberduck-vba/Rubberduck] pflugs30 commented on RubberduckTests/Symbols/SelectedDeclarationProviderTests.cs of pull request #6063: Fixing various build issues in VS2022 (64-bit)

Duga

16:41

[rubberduck-vba/Rubberduck] pflugs30 created comment on pull request #6063: Fixing various build issues in VS2022 (64-bit)

> > Please don't merge until confirmed that this builds OK on VS 2022 64-bit. It did build OK on VS 2019 32-bit but that's only half of the equation.

Thank you for picking up the ball and advancing further. Unfortunately, I can't compile the `Rubberduck.sln` solution anymore with the same error as before:
![image](https://user-images.githubusercontent.com/4409272/210091688-e267c6ab-f549-4b17-bfd9-646cd7cad9b6.png)

I checked the output from `RubberduckMeta.sln`, and the build process copi

Duga

16:52

[rubberduck-vba/Rubberduck] bclothier created comment on pull request #6063: Fixing various build issues in VS2022 (64-bit)

> > I checked the output from RubberduckMeta.sln, and the build process copied the Olewoo x86 DLLs

Just to rule this out - have you tried from a clean build? I'm not sure it'll be smart enough to replace the DLLs if it exists already from prior builds.

> Also, this may sound picky, but I recommend we use "x86" instead of "x32".

FWIW, I dislike it because it sorts higher than the 64-bit and could be read as 86 > 64 when in fact it's 64 > 32 and the term "x86" could easily encompass both

Duga

17:16

[rubberduck-vba/Rubberduck] pflugs30 created comment on pull request #6063: Fixing various build issues in VS2022 (64-bit)

> Yes, I did try clean builds. Here are the build outputs:
[Uploading BuildOutput.zip…]()

> FWIW, I dislike it because it sorts higher than the 64-bit and could be read as 86 > 64 when in fact it's 64 > 32 and the term "x86" could easily encompass both 32-bit and 64-bit (it even started out as 16-bit). That said, I'm not terribly attached to the "x32" naming convention as long as it's consistent everywhere else.

I completely understand that perspective. I wish "the powers that be" hadn'

[rubberduck-vba/Rubberduck] pflugs30 edited comment on pull request #6063: Fixing various build issues in VS2022 (64-bit)

> Yes, I did try clean builds. Here are the build outputs:

> FWIW, I dislike it because it sorts higher than the 64-bit and could be read as 86 > 64 when in fact it's 64 > 32 and the term "x86" could easily encompass both 32-bit and 64-bit (it even started out as 16-bit). That said, I'm not terribly attached to the "x32" naming convention as long as it's consistent everywhere else.

I completely understand that perspective. I wish "the powers that be" hadn't named it "x86". But since i

[rubberduck-vba/Rubberduck] pflugs30 edited comment on pull request #6063: Fixing various build issues in VS2022 (64-bit)

> Yes, I did try clean builds. Here are the build outputs:
[BuildOutput.zip](https://github.com/rubberduck-vba/Rubberduck/files/10325681/BuildOutput.zip)

> FWIW, I dislike it because it sorts higher than the 64-bit and could be read as 86 > 64 when in fact it's 64 > 32 and the term "x86" could easily encompass both 32-bit and 64-bit (it even started out as 16-bit). That said, I'm not terribly attached to the "x32" naming convention as long as it's consistent everywhere else.

I complete

Duga

17:36

[rubberduck-vba/Rubberduck] pflugs30 created comment on pull request #6063: Fixing various build issues in VS2022 (64-bit)

> Looking through the `RubberduckMeta.sln` build output, I found this snippet where the process resolved the references:
```
2> Primary reference "olewoo, Version=1.2.6710.37528, Culture=neutral, PublicKeyToken=null".
2> Resolved file path is "C:\dev\personal\Rubberduck\Rubberduck.Deployment.Build\OleWoo\x32\olewoo.dll".
2> Reference found at search path location "{CandidateAssemblyFiles}".
2> Found related file "C:\dev\personal\Rubberduck\Rubberduck.Deployment.Build

Duga

17:55

[rubberduck-vba/Rubberduck] pflugs30 edited comment on pull request #6063: Fixing various build issues in VS2022 (64-bit)

> Looking through the `RubberduckMeta.sln` build output, I found this snippet where the process resolved the references:
```
2> Primary reference "olewoo, Version=1.2.6710.37528, Culture=neutral, PublicKeyToken=null".
2> Resolved file path is "C:\dev\personal\Rubberduck\Rubberduck.Deployment.Build\OleWoo\x32\olewoo.dll".
2> Reference found at search path location "{CandidateAssemblyFiles}".
2> Found related file "C:\dev\personal\Rubberduck\Rubberduck.Deployment.Build

Duga

18:12

[rubberduck-vba/Rubberduck] pflugs30 created comment on pull request #6063: Fixing various build issues in VS2022 (64-bit)

> I'd like to report another test which failed. I set up an x86 platform for both solutions, and I added an `Architecture` attribute to the `Rubberduck.Deployment` project:

```
<UsingTask TaskName="RubberduckPreBuildTask" AssemblyFile="..\Rubberduck.Deployment.Build\bin\Rubberduck.Deployment.Build.dll" Architecture="x86" />
<UsingTask TaskName="RubberduckPostBuildTask" AssemblyFile="..\Rubberduck.Deployment.Build\bin\Rubberduck.Deployment.Build.dll" Architecture="x86" />
```

Even a

[rubberduck-vba/Rubberduck] pflugs30 created comment on pull request #6063: Fixing various build issues in VS2022 (64-bit)

> I think we've run into an actual bug with MSBuild...
https://github.com/dotnet/msbuild/issues/2360

Duga

18:33

> I noticed a simple typo in the base project SDK version. Quick correction

[rubberduck-vba/Rubberduck] pflugs30 created comment on pull request #5982: Build Fixes

> @Vogel612 I will keep on the task until the project builds in VS2022 (though that may need to wait until a new MSBuild version is available! see here). Feel free to delete this PR.

Duga

19:01

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot created comment on pull request #6065: Correcting a typo in Project.Sdk

> :white_check_mark: Build Rubberduck 2.5.2.6219 completed (commit github.com/rubberduck-vba/Rubberduck/commit/a6ab966785 by @pflugs30)

[rubberduck-vba/Rubberduck] build for commit 6cd265e9 on unknown branch: AppVeyor build succeeded

Mathieu Guindon

19:17

Star destroyer completed... damn that thing is huge

this

bigger than Earth? looks out the window but it's overcast

Mathieu Guindon

About 2ft long =)

Duga

19:35

[rubberduck-vba/Rubberduck] bclothier synchronized pull request #6063: Fixing various build issues in VS2022 (64-bit)

[rubberduck-vba/Rubberduck] bclothier created comment on pull request #6063: Fixing various build issues in VS2022 (64-bit)

> Actually, I don't think the MSBuild bug as reported is applicable here. The project is Any CPU that's referencing a unmanaged C++ DLL that is not a part of the build process (e.g. we're just copying around the DLL). I got a VS2022 instance set up and from my testing, it appears that the issue is that Visual Studio won't update the reference if it already is present. Therefore, we must force it to remove the existing reference, then re-add it and it will then use the correct reference and bui

Duga

20:01

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot created comment on pull request #6063: Fixing various build issues in VS2022 (64-bit)

> :white_check_mark: Build Rubberduck 2.5.2.6220 completed (commit github.com/rubberduck-vba/Rubberduck/commit/b411396942 by @bclothier)

[rubberduck-vba/Rubberduck] build for commit ef03e1f1 on unknown branch: AppVeyor build succeeded

this

@MathieuGuindon just making sure --- this PR modified the yml to use VS2022. Any reasons/concerns whether we should let it through or stay with 2019 as is w/ current next?

Mathieu Guindon

If RD builds since in VS2022 I see no reason to stick with 2019

that's great news, I wonder how close to the latest LTS we could get the build to get

this

do they still do .NET FX?

we still are kind of stuck on FX until we figure how to abstract out the type library generation which is not there in .NET Core.

Mathieu Guindon

I don't think so. 4.8 would be ideal if we're stuck on Framework

this

or delegate it all to tB shim.

Mathieu Guindon

20:11

IIUC 4.8 works with net standard

@this yeah?

How much can tB do for RD at this point anyway?

I'm going to be implementing the Json RPC spec either way

Duga

[rubberduck-vba/Rubberduck] bclothier created comment on pull request #6063: Fixing various build issues in VS2022 (64-bit)

> Just as a FYI - even though the AV's VS is 2022, it apparently uses [32-bit MSBuild](https://ci.appveyor.com/project/rubberduck-vba-releasebot/rubberduck/builds/45805026?fullLog=true#L589). On my VS2022, it came out with "x64". Go figure.

> Resolved MSBuild Bitness: x32

this

@MathieuGuindon act as a proxy for the COM objects so we don't have to deal with lifecycle & releases? Keep all the COM handling out of the RD's server component entirely?

Mathieu Guindon

Also so far RD3 works fine in win11, but the part that overrides some WinForms native stuff isn't there, I hope we won't need it

@this there's zero VBIDE anything on the server side, that'll all be in the add-in itself

this

Correct. I was thinking of the add-in code

Mathieu Guindon

Oh, so it could replace some of VBEditor then

The wrappers and COM stuff

this

20:17

or at least have tB manage the VBEDitor DLL stuff (so it's in the control, not the other way around) while providing the proxy to the server.

but ideally I think we want the add-in itself to be unmanaged and talking to the server component using... something but not COM.

Duga

[rubberduck-vba/Rubberduck] pflugs30 created comment on pull request #6063: Fixing various build issues in VS2022 (64-bit)

> Thanks for sticking with this issue to the end. I pulled all changes and was able to build all projects successfully! I'm going to try the tests again, but I wanted you to know ASAP.

Mathieu Guindon

My understanding was that there was an assembly (using the InternalApi for that) that would define the interfaces and be referenced by both the client and the server; still foggy about how it all works, but was thinking it would "just work" with the protobuf attributes

IOW I was hoping to not have to deal with http and sockets directly

this

yeah makes sense. we definitely don't want to go too low level

Mathieu Guindon

Bleh, the parser pieces aren't even put back together anyway, one bite at a time

Damn I suck at making small commits

this

the main thing is that we just don't want to have a scenario where a server something accidentally holds onto a client's COM thing. We want it weak ref all the way. Sorta.

@MathieuGuindon it takes a commitment to make small commits. :)

(am guilty of the same)

Mathieu Guindon

20:29

So... I gather that the PR is good for merging now? Thanks so much for helping with this!

this

I would think so - tests did pass on the AV and that's the standard. TBH I didn't run tests on my VSs.

Duga

[rubberduck-vba/Rubberduck] retailcoder pushed 11 commits to next (only showing some of them below)

[rubberduck-vba/Rubberduck] pflugs30 pushed commit 1c8e6219 to next: Fixing a failing test

[rubberduck-vba/Rubberduck] pflugs30 pushed commit ef64beb7 to next: Converted the extensibility reference in the Rubberduck.Main project from using the MS Build Tools Program Files install to using the Microsoft.VisualStudio.Interop NuGet pac

[rubberduck-vba/Rubberduck] build for commit ef03e1f1 on next: 97.58% (target 0.00%)

[rubberduck-vba/Rubberduck] pflugs30 pushed commit c74b79b5 to next: Brazenly changing the Appveyor template to use VS 2022 instead of 2019 to force it to use the 64-bit MS Build.

[rubberduck-vba/Rubberduck] bclothier pushed commit 357516d5 to next: Make the olewoo DLLs dependencies conditional based on MSBuild's bitness because it's built with unamanged C++ and thus cannot be compatible with "Any CPU" so we have to load the

[rubberduck-vba/Rubberduck] bclothier pushed commit 4f3d0d25 to next: Merge branch 'fix/build-issues' of github.com/pflugs30/Rubberduck into fix/build-issues

[rubberduck-vba/Rubberduck] bclothier pushed commit 66c5258e to next: Remove the construction debris...

[rubberduck-vba/Rubberduck] bclothier pushed commit aa304444 to next: Revert the test that was failing in AppVeyor to prior state.

[rubberduck-vba/Rubberduck] bclothier pushed commit 7be08c19 to next: Fix the Code Analysis tests not running because of outdated & missing nuget packages.

[rubberduck-vba/Rubberduck] bclothier pushed commit ef03e1f1 to next: Tweak to make Visual Studio being stupid about references.

[rubberduck-vba/Rubberduck] web-flow pushed commit 153d5d7b to next

Merge pull request #6063 from pflugs30/fix/build-issues

Fixing various build issues in VS2022 (64-bit)

Mathieu Guindon

I love that the website just picks up the webhook and updates itself automatically on merge

Duga

[rubberduck-vba/Rubberduck] bclothier created comment on pull request #5982: Build Fixes

> Closing this since the PR #6063 address the issues

[rubberduck-vba/Rubberduck] bclothier rejected pull request #5982: Build Fixes

[rubberduck-vba/Rubberduck] pflugs30 created comment on pull request #6063: Fixing various build issues in VS2022 (64-bit)

> FWIW, I'm still getting the failure in the one test:
![image](https://user-images.githubusercontent.com/4409272/210110138-62fdaf33-0c12-4512-bfd8-3182ad476511.png)

```
Identify_NamedParameter_Parameter_FromExcel
Source: SelectedDeclarationProviderTests.cs line 515
Duration: 1.7 sec

Message:
Expected: <Rubberduck.Parsing.Symbols.ParameterDeclaration>
But was: <Rubberduck.Parsing.Symbols.ParameterDeclaration>

Stack Trace:
SelectedDeclarationProviderTests.Ident

[rubberduck-vba/Rubberduck] bclothier created comment on pull request #6063: Fixing various build issues in VS2022 (64-bit)

> I would think it unlikely. On my VS2022, it passes. I would treat this as a separate issue, beyond the scope of the PR.

[rubberduck-vba/Rubberduck] pflugs30 opened issue #6066: Failing test: Identify_NamedParameter_Parameter_FromExcel

> While working on #6063, I encountered a single failing test:
![image](https://user-images.githubusercontent.com/4409272/210110138-62fdaf33-0c12-4512-bfd8-3182ad476511.png)

```
Identify_NamedParameter_Parameter_FromExcel
Source: SelectedDeclarationProviderTests.cs line 515
Duration: 1.7 sec

Message:
Expected: <Rubberduck.Parsing.Symbols.ParameterDeclaration>
But was: <Rubberduck.Parsing.Symbols.ParameterDeclaration>

Stack Trace:
SelectedDeclarationProviderTes

[rubberduck-vba/Rubberduck] retailcoder created comment on issue #6066: Failing test: Identify_NamedParameter_Parameter_FromExcel

> Nah, that was me messing up my local build - fixing the test should be as simple as changing its expectations to match the actual.

[rubberduck-vba/Rubberduck] bclothier created comment on issue #6066: Failing test: Identify_NamedParameter_Parameter_FromExcel

> @retailcoder but this is passing on both VS 2019, VS 2022 and on AV's VS 2022?

I think there's something about the Excel library. I don't think it's a 32/64 bit thing but rather the Excel library, need to double check what it's using.

[rubberduck-vba/Rubberduck] bclothier created comment on issue #6066: Failing test: Identify_NamedParameter_Parameter_FromExcel

> @pflugs30 , could you grab the XML files from this path:

`.\RubberduckTests\bin\Testfiles\Resolver` and zip it up and post it here? I want to do a diff on those files.

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot prereleased draft prerelease Prerelease-v2.5.2.6221

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot created draft prerelease Prerelease-v2.5.2.6221

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot created tag Prerelease-v2.5.2.6221

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot published prerelease Prerelease-v2.5.2.6221

[rubberduck-vba/Rubberduck] build for commit 153d5d7b on next: AppVeyor build succeeded

[rubberduck-vba/Rubberduck] build for commit 153d5d7b on next: 97.58% (target 0.00%)

Feeds

21:12

[Earlier, at the eye doctor] 'No, for the last time, the numerals on the paper aren't my prescription, it's the shape I want you to make with the laser.'

Duga

21:34

[rubberduck-vba/Rubberduck] pflugs30 pushed commit 6cd265e9 to next: Correcting a typo in Project.Sdk

[rubberduck-vba/Rubberduck] web-flow pushed commit db232a41 to next: Merge pull request #6065 from pflugs30/fix/correct-base-project-sdk-version

[rubberduck-vba/Rubberduck] build for commit 6cd265e9 on next: 97.58% (target 0.00%)

Duga

22:00

[rubberduck-vba/Rubberduck] retailcoder created comment on issue #6066: Failing test: Identify_NamedParameter_Parameter_FromExcel

> FYI I sent you an invite to the RD org; if you accept the invite you'll be an "official" contributor and will be able to label issues and get access to the RD3 private repository: feel free to look around, but note that I have a ton of local changes yet to be pushed there.

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot created draft prerelease Prerelease-v2.5.2.6222

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot prereleased draft prerelease Prerelease-v2.5.2.6222

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot created tag Prerelease-v2.5.2.6222

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot published prerelease Prerelease-v2.5.2.6222

[rubberduck-vba/Rubberduck] build for commit db232a41 on next: AppVeyor build succeeded

[rubberduck-vba/Rubberduck] build for commit db232a41 on next: 97.58% (target 0.00%)

Duga

22:15

[rubberduck-vba/Rubberduck] pflugs30 created comment on issue #6066: Failing test: Identify_NamedParameter_Parameter_FromExcel

> > @pflugs30 , could you grab the XML files from this path:
>
> `.\RubberduckTests\bin\Testfiles\Resolver` and zip it up and post it here? I want to do a diff on those files.

Sorry for the delay... I'm having trouble getting the files uploaded to Github for some weird reason. If they won't go up soon, then I'll try another method.

Duga

22:42

[rubberduck-vba/Rubberduck] pflugs30 created comment on issue #6066: Failing test: Identify_NamedParameter_Parameter_FromExcel

> > FYI I sent you an invite to the RD org; if you accept the invite you'll be an "official" contributor and will be able to label issues and get access to the RD3 private repository: feel free to look around, but note that I have a ton of local changes yet to be pushed there.

Thank you very much! I'm happy to be a part of the team. I'm looking forward to contributing, particularly with unit testing. I think you may have known that already... 😏

[rubberduck-vba/Rubberduck] pflugs30 created comment on issue #6066: Failing test: Identify_NamedParameter_Parameter_FromExcel

> > @pflugs30 , could you grab the XML files from this path:
>
> `.\RubberduckTests\bin\Testfiles\Resolver` and zip it up and post it here? I want to do a diff on those files.

Here's a link to the files. I'm not sure why Github isn't working...
https://file.io/HcdmSmVHc6ct

Duga

23:03

[rubberduck-vba/Rubberduck] pflugs30 created comment on issue #6066: Failing test: Identify_NamedParameter_Parameter_FromExcel

> Here are the files! They finally uploaded...
[Resolver.zip](https://github.com/rubberduck-vba/Rubberduck/files/10326438/Resolver.zip)

Duga

23:31

[rubberduck-vba/Rubberduck] bclothier created comment on issue #6066: Failing test: Identify_NamedParameter_Parameter_FromExcel

> Unfortunately they seem to be 100% identical. Will have to look somewhere else.

[rubberduck-vba/Rubberduck] pflugs30 created comment on issue #6066: Failing test: Identify_NamedParameter_Parameter_FromExcel

> @bclothier I'm running the tests again on a fresh VM with a clean VS2022 install and NO installation of MS Office of any kind. With only 4 GB RAM, the tests may take a while, so I'll send an update in a bit. The good news is the builds went super smooth! :-)

Duga

23:53

[rubberduck-vba/Rubberduck] 1690 stars vs. [decalage2/oletools] 2295 stars

Transcript for