Where is the Upgrade Path for C# 6.0? Is it safe yet?

Question

I maintain a large number of projects, all currently written in .Net 4.5 / c# 5. I'm interested in upgrading to C# 6.0, but cannot find any documentation on the safety of doing so.

From what I've read, upgrading to VS 2015 / C# 6 / .Net 4.6 means building our code using Roslyn / RyuJit. (Or with msbuild 14, which uses Roslyn under the hood).

Roslyn, however, has a massive amount of open issues currently: https://github.com/dotnet/roslyn/issues/7278 Many of which are guaranteed to impact our codebase.

Similarly, RyuJit appears to be completely unstable, as recently as 6 months ago (http://nickcraver.com/blog/2015/07/27/why-you-should-wait-on-dotnet-46/)

I simply cannot find any documentation, anywhere, on safely upgrading to C# 6.0 / .Net 4.6, and yet find it extremely strange that these things are already released to RTM and VS 2015 with so many bugs out in the open.

Help?

Answer 1

Many of which are guaranteed to impact our codebase.

I wouldn't be so sure. We are building not just Roslyn with itself, but the rest of Visual Studio, the entire .NET Framework, Windows, ASP.NET, and more with Roslyn, and have been doing so for two years now. We did test passes where we literally downloaded thousands of projects from GitHub so we could verify that code that built with the old compiler would build with the new compiler. We take compatibility with the old compilers very, very seriously.

with so many bugs out in the open.

There's a few things to know about that bug count:

1. That includes not just the compiler, but also IDE, refactorings, debugger, and a lot of other components.
2. That count includes bugs for features that haven't shipped yet. For example, a few days ago we started testing a new compiler feature that we hope to ship in C# 7, and filed 30-40 bugs on various IDE features that need to be updated to know about it.
3. We file bugs for things that don't affect you. For example, any time we have a problem with one of our automated tests, we file a bug. Any time somebody realizes "huh, we could clean this up", we file a bug. We even use "issues" to discuss future language proposals as a forum, rather than a bug itself. Right now I have an issue against me which is to write a blog post that needs to be written.
4. Some of these aren't actually bad bugs; they include issues like "I wish the compiler gave better error messages."
5. Many of them involve running Roslyn on Linux or Mac, which is still actively under development.

If we filter to the actual list of "compiler" bugs and filter out compiler bugs for features that haven't shipped, the count is much much smaller.

And the most important bit:

6. There were always bugs, in every release of the compiler. The compiler is a piece of software being written by humans, so it is by definition not perfect. We're just choosing to air our dirty laundry on GitHub instead of hiding it behind our firewall!

This is of course not to say that you won't hit a bug, but we've tried our best to make Roslyn as best a compiler as we can, with the best compatibility we can. If we had to write a document that said "here's all the ways your code isn't compatible", that would mean we failed at that. As usual, always test a bit of stuff before deploying, but that's no different than anything else.