Geek Answers Handbook

Where is the update path for C # 6.0? Is it still safe?

I support a large number of projects, all of which are currently written in .Net 4.5 / C # 5. I am interested in upgrading to C # 6.0, but cannot find any security documentation.

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

However, Roslyn has a huge number of open issues: https://github.com/dotnet/roslyn/issues/7278 Many of them are guaranteed to affect our code base.

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

I just can’t find any documentation anywhere, safely upgrading to C # 6.0 / .Net 4.6, but it’s still very strange that these things are already released in RTM and VS 2015 with so many open access errors.

reference

+6
source share
1 answer

Many of them are guaranteed to affect our code base.

I would not be so sure. We are building not only Roslyn with us, but the rest of Visual Studio, the entire .NET Framework, Windows, ASP.NET and much more with Roslyn, and we have been doing this for two years now. We checked the passages where we literally downloaded thousands of projects from GitHub so that we can make sure that the code built with the old compiler will be built with the new compiler. We take old compilers very seriously.

with so many open access errors.

There are a few things you need to know about this number of errors:

  • This includes not only the compiler, but also the IDE, refactoring, debugger, and many other components.
  • This account contains errors for functions that have not yet been sent. For example, a few days ago, we started testing a new compiler function, which we hope to send to C # 7, and filed 30-40 errors for various IDE functions that need to be updated to find out.
  • We register errors for things that do not affect you. For example, every time we encounter a problem with one of our automatic tests, we report an error. Every time someone realizes, “Yes, we could clear it,” we give an error. We even use “problems” to discuss future language sentences as a forum, not the error itself. Right now, I have a problem against me that is to write a blog post to write.
  • Some of them are not really bad mistakes; they include issues like I want the compiler to give better error messages.
  • Many of them are related to the launch of Roslyn on Linux or Mac, which is still being actively developed.

If we filter the actual list of "compiler" errors and filter out compiler errors for functions that were not sent, the number is much smaller .

And the most important bit:

  1. There have always been errors in every version of the compiler. A compiler is a piece of software written by people, so by definition it is not perfect. We just decided to release our dirty laundry on GitHub instead of hiding it behind our firewall!

This, of course, does not mean that you will not make a mistake, but we tried to make Roslyn the best compiler, as far as we can, with the best compatibility. If we had to write a document that said "here are all the ways that your code is incompatible," this would mean that we failed. As usual, always check a few things before deploying, but this is no different than anything else.

+11
source

More articles:


All Articles