Roslyn: Question - Compiler releases

[Korporal]

This is a question.

Can someone please explain why it is always necessary to associate an update to the C# language with a Visual Studio release?

For example the latest language updates (local methods, tuples etc) why can't these be made available to Visual Studio 2015 users as just a compiler upgrade?

Thanks

[HaloFour]

IIRC each of those features requires a fair amount of support written into the IDE, otherwise it wouldn't be able to provide any form of formatting, checking, autocomplete, refactoring, etc. But I do understand that the team intends to be able to ship minor feature updates out of band. I imagine doing so would require shipping minor VS updates.

[jnm2]

otherwise it wouldn't be able to provide any form of formatting, checking, autocomplete, refactoring, etc

It could be more modularized in theory.

[eyalsk]

@jnm2, @HaloFour I'm pretty sure it possible to do that today, if you can build and run Roslyn on VS 2015 Update 3 and then test its features on the experimental instance you probably can enable that for the non-experimental instance, I'm not sure what it requires but I'm pretty sure it's possible, so the infrastructure to do it is probably there.

_p.s. I don't know whether it's a good idea to do that unofficially and why one would want to do it but I wrote that just to indicate that I think the infrastructure is there._

[CyrusNajmabadi]

For example the latest language updates (local methods, tuples etc) why can't these be made available to Visual Studio 2015 users as just a compiler upgrade?

If it's just a compiler upgrade, then you won't get any IDE support at all and it will be very difficult to use those features. If you want IDE support then we need to update the IDE bits. However, as we're doing that, we're also continuously upgrading the IDE bits for other reasons. For example, we're making more and more of our internal feature code public:

https://github.com/dotnet/roslyn/commit/4445deb5cd2342fa00000e66d19f39ae68b8ab42

This sort of work ends up greatly changing a lot of code. So, if we wanted to do what you wanted we'd have to both:

1. Update the compiler to support the new language features.
2. Update the IDE code that uses the old VS APIs to use the new compiler.
3. Update the IDE code that uses the new APIs to the user the new compiler.

Supporting '2' is a lot of work. And it means we're essentially maintaining two ways to do things. Now, consider that this will happen with us with many feature across many releases, and you'll understand why we're reluctant to do this.

As such, we cut out '2' and only '1' and '3'.

[eyalsk]

@CyrusNajmabadi Isn't this what happens today? I mean you can build Roslyn on VS 2015 Update 3 and VS 2017 RC and tests features on both.

_Maybe I'm missing something and it's not related. :)_

[jmarolf]

@eyalsk you can build of course, but you can't open the roslyn solution in VS 2015 Update 3 without getting errors in the editor which is why we recommend you install this experimental vsix in the build/debug directions.

To be clear, in our process we currently have two IDE vsixes, Setup and Setup.Next. Setup contains all the functionality that we haven't moved to be on 2017 APIs and works on VS 2015 Update 3, Setup.Next only works with VS 2017. Over the course of this release we moved more and more functionality from Setup to Setup.Next as the need arose. We are OK supporting both VS 2015 Update 3 and VS 2017 for a short amount of time while 2017 is not released so open source development on windows is easier. However, once VS 2017 releases we do not want to keep supporting VS 2015 Update 3 for several reasons, but mainly because we don't want to support all versions of VS. We don't want to have the support cost of making sure that every language feature is supported on VS 2015 Update 3, VS 2017 and VS.Next. Two is already very difficult.

[eyalsk]

@jmarolf Ahh, this makes sense, thanks! :)

[jcouv]

I'll go ahead and close the issue, since it was answered. Thanks