Merging the PR will mean that we no longer can use Visual Studio 2017; all contributors must start using Visual Studio 2019 after the merging. As a benefit, we are able to remove all the hacky workarounds that was put in place to support WinForms/WPF when we migrated to SDK-style project format. However, we need to test that we are able to build on AV correctly.
Something ain't right about AppVeyor. I'm logged in the AV, and I noticed that the builder image was reported as Visual Studio 2015 which doesn't makes sense since the log says it's using Visual Studio 2017. I changed the image to Visual Studio 2019, and the build still fails, reporting that it's using 2017.
When I try to start AV, it randomly picks a commit from.... whatever.
and it won't let me restart my own commit. Logical!
So if anyone who has access to the real Rubberduck account on AV, I'd appreciate if we can check whether it builds using 2019 image.
> If this PR will invalidate any Visual Studio prior to 2019 it may be prudent to give a couple weeks notice before merging. I know I'd be at a loss right now as I am still on VS2017 and am really out of the RD development loop.
I've just started to use Rubberduck. I would like to say to authors (Mathieu?) THANK YOU SO MUCH! My code isn't optimal yet, but it is A LOT better after reading messages in Code Inspections menu
I've been using AppVeyor for about 6 months now on three different projects. I cringe every time I need to touch the appveyor.yml; it always feels like an exercise of PDD -- prayer-driven development: copy-paste various things, and randomly fiddle with the syntax until AppVeyor accepts it. Any suggestions as to what I am doing wrong?
In my case, I think it's because I'm not really Rubberduck.
Rubberduck has a team org and AV is connected to it. I can access some stuff but not as Ruberduck, only as me. That's the only explanation I can come up with what I saw last night.
Rubberduck can't possibly have been building on Visual Studio 2015.
The main problem with AV as I see it is that there's no simple way to test besides actually running it. That's why it's so PDD-ish.
@ZevSpitz I am not familiar with VS extension stuff but is it truly impossible to build a 2017 extension using 2019?
It's certainly possible to build the visualizer (different from VSIX extensions BTW) with 2019, but because the 2017 version needs to target a different version DLL, it requires 2017 to be installed. If AppVeyor had some image that had both VS 2019 and 2017 installed I could use that.
I'm thinking that just by including the DLL only for the build purpose, you'll get a working visualizer without having to do via a 2nd AV build or deal w/ excluding project which apparently doesn't work.
oh, one more thought just to be sure - you did explicitly exclude the build for all configurations, right?
One way would be to call their anti-piracy hotline.
@MathieuGuindon when you could, you please confirm whether RD AV is using 2017 image? My AV settings seems to do nothing whatsoever and I need to use 2019 image to verify the build of the PR.
> The earliest it can merge would be Nov 1st, and even so, I don't know it'll merge that early. More likely, we'll want to do that after our green release, which is likely to be in mid-November anyway.
Build articles will be updated as well, so you can consider this PR your advance warning. :)
> MSBuild auto-detection: using msbuild version '16.3.1.50202' from 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin'.
Just making sure - in SQL I have columns MyLongText nvarchar(500) and MyShortText nvarchar(2). If I store 'No' in both columns - they both take up the same amount of space, right?
Loop through foo and get the results begat loop through bar begat loop through duk begat loop through buzz begat loop through irmaGourdPleezStopWithTheLoopThrough O(n^6) is about the order I'm on presently. No small time for it to complete...
@IvenBach that's what you get for naming your variables foo, bar, duk, buzz, and irmaGourdPleezStopWithTheloopThrough. I mean, other than that last one, they're not very descriptive...
> Following my submission for #5135, some bugs were raised. These were: 1) Auto-scrolling when clicking a cell. This has now been fixed with an event handler which stops the RequestBringIntoView event from reaching the ScrollViewer. 2) "After using the scrollbar and collapsing a grouping, expanding it again makes the scrollbar default to the far right hand side" - instead of placing the ScrollViewer inside the DataGrid, I put the DataGrid inside the ScrollViewer. Now it's actually appearing...
in the correct place and no longer behaves erratically. Closes #5237.
> this was based off of the state of next from 16 days ago and as such had some conflicts. You should update your local repository with the development progress to avoid things like this in the future ;)
> Whenever I do a pull in Visual Studio it says my "next" branch is up to date. And yet the latest commit I see when I View History is from 8th October? What am I doing wrong? I have run a Sync, Fetch and Pull on my "next" branch.
> @glowingrunes you want to git pull upstream next, i.e. bring in the remote commits from the main (this) repository; when you do that the Team Explorer in VS should mention something about merge conflicts, and present a "merge" button - clicking it brings up the conflict resolution tooling.
> @glowingrunes I think the issue is that you're only pulling from your fork of the codebase. You will need to add this repository here to the remotes available in your local git repository using something like:
> @glowingrunes you want to git pull upstream next, i.e. bring in the remote commits from the main (this) repository; when you do that the Team Explorer in VS should mention something about merge conflicts, and present a "merge" button - clicking it brings up the conflict resolution tooling.
> Hmm, running into a problem when trying to fetch upstream. ```
A:\repos\Rubberduck>git fetch upstream The authenticity of host 'github.com (140.82.118.4)' can't be established. RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8. Are you sure you want to continue connecting (yes/no/[fingerprint])? y Please type 'yes', 'no' or the fingerprint: yes Warning: Permanently added 'github.com,140.82.118.4' (RSA) to the list of known hosts. git@github.com: Permission den
> do you have an SSH key registered with your github identity? If not you'll want to use the https cloning. You can accomplish that by changing the remote's url using
@Vogel612 ok, I'm confused now. Why did you bring telnet into the conversation if it's not supported? I was referring to the syntax git remote add upstream git@github.com:rubberduck-vba/Rubberduck.git
there is nothing saying "use ssh", so I inferred that the user@domain was what makes it uses ssh
No, it isn't possible.
Even 13 years ago telnet wasn't an acceptable protocol to use, and ssh was already supported by any server worth using. That's even more the case now.
You may be able to set up support for doing git over http, including pushes. But you should really see about getting some...
I'm somehow not surprised that somebody out there tried it..
yea, apparently you can get git to actually work via arbitrary connection interfaces, so long as you properly route the commands on the other end:
> Data written to stdin of the specified <command> is assumed to be sent to a git:// server, git-upload-pack, git-receive-pack or git-upload-archive (depending on situation), and data read from stdout of <command> is assumed to be received from the same service.
> There were 2 issues, #5133 and #5135, which were to add a horizontal scrollbar to the Test Explorer and Code Inspections window, respectively. I added similar code to both, so I thought it best to add the fix for #5237 not only to the Code Inspection window but the Test Explorer as well. My pull request for #5133 had already been merged in, so I updated my pull request for #5135 which is still pending.
I'm still new to Rubberduck, so if you could give me a list of the other tool windows tha
Code Explorer Todo Explorer Test Explorer Code Inspection Results
We have few more XAML dialogs (e.g. Settings, RegEx Assistant) but they aren't used in a toolwindow so I think they don't necessarily need the same behavior.
No, it isn't possible.
Even 13 years ago telnet wasn't an acceptable protocol to use, and ssh was already supported by any server worth using. That's even more the case now.
You may be able to set up support for doing git over http, including pushes. But you should really see about getting some...
VBA Rubberducking
VBA Rubberducking