Drop support for VS2017 - enable support for newer language features

[GrahamTheCoder]

I've updated #16 to point to 8.5.0 - the last release that supported VS2017

---

I've already updated the readme to update the intended minimum supported version (VS2019).

I believe that as of March 2022, VS2017 is out of "Mainstream support". Either way, continuing to support it would be a significant burden.

The reason that the CodeConverter project is pinned at 2.8.2 was to support VS2017 - it binds to whichever version Visual Studio loads. For the command line and web, it's fine to bundle later versions, which may fix bugs and improve handling of some syntax types.

To update it we'll need to:

• Remove 2017 from the vsixmanifest (by increasing the required version there)
• Update all dependencies with a 2.8.2 version to the latest version supported by the latest version of VS2019 (latest 3.x)
• Update all dependencies that look Visual Studio related and start with version 15, to the latest version 16
• Update the dependencies in this horrible hack to the versions available in a minimal install of VS2019: https://github.com/icsharpcode/CodeConverter/blob/master/Vsix/Vsix.csproj#L80-L99
  • See if we can (or need to) remove this horribe hack. It was required because VS2017 was missing these common assemblies
• Update readmes and changelog to link to the last working VS2017 version clearly (ideally add a clear message in that version that reminds them there are more features and bugfixes if they use vLatest).
• Test with VS2019 and VS2022

[christophwille]

I'd suggest an even more radical approach - move to 2022 entirely. Because if you need the CodeConverter, you can always install the Community edition to do the conversion.

Also, you might want to look into https://github.com/VsixCommunity/Community.VisualStudio.Toolkit to replat the extension onto.

[Yozer]

From my experience, I can tell that people tend to convert VB->C# code piece by piece, and having two VS installations can be trouble (opening large solution in another VS instance just to convert code, disk space etc).
I'm not sure if forcing people to install VS2022 is a good idea (are there any benefits for us?).
If we could use abstractions that Community.VisualStudio.Toolkit gives then switching later from VS2019 to VS2022 shouldn't be that painful.

Do we have any statistics about VS versions that people use when installing extensions?
https://marketplace.visualstudio.com/items?itemName=SharpDevelopTeam.CodeConverter

[GrahamTheCoder]

Always worth throwing in radical suggestions! In this case, I don't think it makes sense for reaching the most users, and there isn't a major benefit to it from a development standpoint that balances the downside.

@Yozer I don't recall those stats existing (might not help massively since you can download from browser anyway), but perhaps @christophwille can check just in case there's anything of use.

Some detail

If people already knew the converter was going to work perfectly for them, and had lots of projects, they probably wouldn't mind installing VS2022 community edition in lots of cases*. The main problem is that when someone arrives at the page, it's just the second or third page they've reached from Google and they want to know right now if it will work, not in an hour (in which they can't any use VS!).

Personally, even though I have a fast machine, when I find a new extension, I often install it then don't bother to restart VS, and only remember about it much later. I know I'm not the only one, I used to work on extensions that contained telemetery and the drop off in the funnel from download -> install -> "ever using" was huge (and I'm assuming it still is some years later).

* To come back to those other cases I hinted at: A bunch of the users of this tool are picking up legacy VB codebases on their last legs. Since every version of Visual Studio drops support for some technologies it means they'd have to do lots of work in the VB codebase to get it into recent technologies before even finding out if the converter will work.

On some of the various issues where things were broken just for some subset of VS2017 users, there are some comments from users about their situations if you're interested:
#775
#563 (comment)
#741
#797 (comment)

Plan

In general I like the policy of supporting the bleeding edge plus previous version "where possible".
i.e. If VS2019 support does become a blocker/burden before vNext is out, I'd still strongly consider dropping it

[christophwille]

No, the stats don't show which version of VS it was installed in (at least I didn't find any such reports).

My suggestion for 2022-only was mostly for one reason: latest Roslyn 4 series.