@Vogel612 I'm looking at resurrecting your PR few months ago because there's useful stuff in there. However, I want to know - were you able to build & run the RD originally? I ask because I have a working build but it cannot load due to runtime error with the System.Resources.Extensions assembly.
Alright. I'm fighting with it because it is trying hard to not find the right version of the assembly, similar to this: stackoverflow.com/questions/64298051/…
It already suggests one same thing that you added in your PR but even so, it's not effectual.
I say "use 7.0.0.0", it bumbles off looking for "4.0.0.0"
all the same result. Builds OK, face-plants when running & loading the DLL
Hmm. Let me try 4 one more time.
Yes confirmed
even after cleaning & rebuiliding (redundant but better to clean out debris) and updating the app.config and using 4 in core & resources, it still face-plants on the load
System.IO.FileNotFoundException: 'Could not load file or assembly 'System.Resources.Extensions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.'
Looking at dependencies, it says that it couldn't find the 4.0 and is using 4.6.0. On the nuget.org that's the lowest version, I guess.
Tada! https://www.nuget.org/packages/ResXResourceReader.NetStandard
I extracted ResXReourceWriter and ResXResourceReader from the Winforms github and packaged them for .NetStandard
Putting it prior to those lines ensure that the dependent assembly is resolved using our custom resolver. The app.config is useless for our binding redirects because we're a DLL, not an EXE.
but then other things break (e.g., I get 4 blank buttons instead of a Parse button), so one step forward, one or two steps backward.
in other news, I've decided that the database server would make a nice little project to start walking with RPC and protocol buffers
:D
I think I'm going to regret implementing the LSP spec without optimizing much. there's... let's just say a lot of room for better abstractions in the model.
idea being that since the spec is alive, having the model mirror it as closely as possible basically removes any assumptions one is allowed to make about how that namespace is going to evolve: it follows a specification, period. but would it be reasonable to interpret the spec a bit and, say, have a ValueSet<T> class for TagSupport, CodeActionKindSupport, and about a dozen others -- instead of a separate type for each one? hm..
/// <summary>
/// Extra annotations that tweak the rendering of a completion item.
/// </summary>
public class CompletionItemTag
{
/// <summary>
/// Render a completion as obsolete, usually using a strike-out.
/// </summary>
public const int Deprecated = 1;
}
got all the database stuff moved to a new Rubberduck.DataServer project; a WPF app with a small window that should end up with "Console" and "Settings" tabs, perhaps.
> FYI restored a working version of this PR as to resurrect the following features:
1. coverlet 2. Wix as a nuget package 3. updates in dependencies where possible
Still need to restore the `dSPACE` nuget and test using its library. This isn't a fully dotnet-buildable solution due to the nature of `.resx` files and the difference in how it's built between the two build systems.
I know there have been shortages due to "supply chain issues", but that's a bit ridiculous... Mug was gone for a while, too. It's nice to have most of the band back together again.
I assume that building via VS uses the non-dotnet msbuild but via AV, it uses the dotnet msbuild which is slightly different from the non-dotnet msbuild.
Damn, building RD3 is such a massive regression I'm questioning the idea of having started it from an empty solution. There's always this "but what if maybe it was possible to do incrementally after all" in the back of my mind...
Maybe the RD3 server projects can just be imported into RD once it all works
Downside is that it's no longer "build with only one build toolchain"
we now have 2 toolchains, and one isn't open sourced.
Though, technically, we are already building with two toolchains right now, only that it's still from single build system (e.g. C++ tools + C# compiler)
that is also what blocks us from being able to use .NET Core
The other thing I'm not 100% sure about is the toolwindows. That still needs to be created somehow. I think we provide the toolwindows from Rubberduck.Core
it's the interaction with the in-process that we're dealing with.
The (yet) other alternative is that the tB addin loads a WebView2 view and communicate using socket with the server rendering the view. The bad thing is that it requires re-tooling of the UI but that would completely remove the UI mess of WinForm+WPF.
that approach means no COM interop (assuming that the tB addin can just perform simple export/import of the VBA project and do not need to access any other COM objects).
a tB addin would remove the registration. The assembly w/ toolwindows need to be COM-visible, and thus provide the toolwindow to the VBIDE via tB addin, i think
huh... I didn't realize that. Coulda sworn you ran into some issues with Avalon itself, licensing, or something that caused you to have to move away from it.
I think the focus should be to get RD3 to work with bunch of files. The add-in is the ugly part and we can deal with it once we have a working RD3 build.... right?
that said there's already a "sync panel" UI that lists all the VBIDE modules and lets you open them in an editor tab - I think eventually this panel might become some kind of "workspace explorer"
quick answer would be to ensure there's at least a skeleton as to avoid future code changes. if it's inevitable that code will be changed to support telemetry, don't worry about it right now.
Yes telemetry. I'm working on a package manager for VBA and really want to drop Win7 - at least while I write it in python (hopefully I can migrate it to twinbasic). Knowing who uses RD would be extremely useful. Knowing how many people use vb6 Vs VBA would colour a lot of the decisions for twinbasic as well. RD is a great "heuristic" userbase for "people willing to run open source Dev tools"
I know people argue corporate IT refuses to install anything with the possibility of data connection. Would be great to know how many of these there were too...
telemetry might be useful shipped as a separate optional dependency, because then we can get antivirus analysis results to back up our segregation for corp IT shenanigans
I can't remember where I saw this. There was a Linux based OS that previewed the actual JSON template of the telemetry data. I thought that was quite slick and combined with open source allows users or IT admins to make very informed decisions
@this I actually meant if we're more interested in OS, VBA version, most used features etc. That could just be a Google survey. Agree LSP/automatic telemetry should be an install time setting. But just that Windows version support/host app was what Matt was after, that could be a survey.
Meh. If RD gets telemetry we might as well collect feature usage data. Minus the annoying "Help make Rubberduck better!" nag/notification when you startup opted-out
Not sure hit rate would be well beyond 1% with a survey link tbh
Apparently Microsoft thinks it's a fine idea to mandate signing in just to use Edge. Was there supposed to be a difference between today's Microsoft and 90s' Microsoft?
Tada! https://www.nuget.org/packages/ResXResourceReader.NetStandard
I extracted ResXReourceWriter and ResXResourceReader from the Winforms github and packaged them for .NetStandard
VBA Rubberducking
VBA Rubberducking