Brave new Roslyn: Who needs their own code analyzers and C # scripting?
In the world of .NET, everything is fine - the platform is moving in the right direction, new technologies run in and stand up. Recently, there has been a lot of talk about .NET / ASP.NET Core, and it seems that everyone has forgotten about Roslyn, which provides extensive documented possibilities for working with code both during runtime and during development.
To fix this, we interviewed Filip W, Microsoft MVP, the contributor to Roslyn, and simply one of the world's most popular ASP.NET bloggers. Why Filip thinks that changes in the new C # can go unnoticed, why write your own code analyzers, and also why scripting in C # is better than any scripting language?
JUG.ru Group: Philip, let's start with warming up. ASP.NET Core is now changing a lot. How do you feel about the changes as a developer working with the platform?
')
Filip W: Of course, the pioneers experienced many problems: postponement, hell with versioning, name changes, problems with tools, inconsistent system of working with projects and much more, up to changes in the .NET Standard concept itself. Can you do better? Definitely yes, but in retrospect everything always looks simple and clear.
If to speak as a whole, absolutely exactly the changes are happening for the better. Just think, a few years ago ASP.NET worked only under Windows and only under IIS. In addition, it was based on System.Web.dll, which was added to each HTTP request by a ridiculous overhead (29Kb on average). Today, ASP.NET Core, according to benchmarks , is one of the top five best-performing web frameworks on Linux. From this point of view, the platform has undoubtedly gone through an incredible transformation.
JUG.ru Group: So you already wrote .NET applications under Linux? Tell me how things are with the stability of such decisions? Is the platform ready for production?
Filip W: Yes, many of my new projects are currently running on Docker on Debian-based systems. I ran into some problems with platform-specific code, such as cryptography, or with strange deadlocks appearing here and there, but on the whole, everything suits me. And of course, the benefits of managing the entire platform via Docker Swarm are impressive.
In fact, we are trying to develop cross-platform .NET code no matter which OS the project is deployed to. As a result, most of our projects have build agents for Windows, macOS and Linux. Thus, I can develop something on my Mac and be able to deploy it at least in Docker, at least in the Azure Web App with the guarantee that everything will work correctly.
JUG.ru Group: What about C #? In version 7.0, we will have tuples, pattern matching, and many other features. Will these innovations be useful for you, as a developer?
Filip W: In general, as in the case of C # 6.0, the changes are minor, so it is likely that many developers in their daily work will not notice the transition to the new version. For me personally, tuples will definitely be useful, since in the current form they are very poorly implemented. I hope this will help drastically reduce the number of auxiliary classes that we are facing now, when a developer is forced to create a new class to deserialize or read one or two fields from the database.
I'm a little upset that the pattern-matching syntax will not be based on expression-ah. Instead, there will be an emphasis on is and switch, however, I understand the rationality of the fact that innovations come step by step. In addition, more expressive elements help to write concise code, and C #, as we know, can be very “wordy”, so such changes are also for the better.
JUG.ru Group: In the past DotNext you talked about scripting under C # . How do you think the report went? Is such a scenario using C # among .NET developers?
Filip W: Oh, I got an incredible audience response! I think scripting is one of the coolest sides of Roslyn, because it provides access to a lot of interesting user cases that were previously inaccessible in the .NET ecosystem. Of course, earlier it was possible to use Powershell, but the ability to write scripts in C # is quite another, considering how close it is to .NET developers. Now you can see a sharp increase in the use of scripts in C # in commercial projects: they implemented Azure Functions, extensions for games and much more. Add to this language services and support for intellisense / debugging for C #, which can be obtained in some lightweight editor, such as VS Code, and you get a very pleasant development process. It's funny that C #, being a non-script language, got such a powerful environment that hardly any of the scripting languages ​​can argue with it in terms of productivity.
In Moscow, in the discussion area, we spent almost two hours discussing the difficulties and ways of using C # scripts: for security, memory management, application expansion (script-based plug-in systems), and even a remote REPL for managing executable processes. It was cool!
JUG.ru Group: In addition to scripting, you also do static code analysis. Tell me, who may need to develop their own analyzer, given that there are VS and Resharper on the market?
Filip W: Our own analyzer is usually needed by timlids, which deal with code review and are generally responsible for the quality of the code in the team. Here it is important to understand that in the development process we are faced with some of our own problems and roughness, relevant only in the context of our project. Both Resharper and VS are universal tools designed for a wide audience, but what if you need to ensure that a particular pattern is used or the code matches your corporate guidelines? For example, establish class / variable naming rules, make sure that your internal API is used only as it was intended, that the code is documented in accordance with your standards, or that HTTP endpoints are developed in accordance with the established standard. Sometimes there are also strange things - I somehow worked in a project where at the compiler level it was forbidden to use tabs and # region-directives.
However, even if you forget about writing your own analyzer, it is important to understand how they work “under the hood”. As in other areas of programming, even if you don’t get your hands on writing your analyzer, it’s very useful to understand the principles that underlie them, as well as how the compiler API works, ensuring the operation of the code analyzer.
JUG.ru Group: Speaking of the compiler, which Roslyn Compiler API made your life easier compared to the previous one?
Filip W: Is this a trick question? In fact, the old compiler did not allow doing anything except feeding the code to it, and getting DLL / EXE files at the output. So for me the most important thing at Roslyn is that this is a real ompiler-as-a-Service, where each step of the pipeline has an external API that can be used in its own way. It is also surprising that before Roslyn there was no official C # AST library (only third-party options could be found).
JUG.ru Group: By the way, what about backward compatibility? What is the probability that my samopisny analyzer will fall apart on the next release of Roslyn?
Filip W: Well, the fact that the Roslyn team pays great attention to backward compatibility, I know for sure! If you delve into the compiler code, you can find incredible examples of this. For example, if searching in the source code of the compiler, you can find the lines "DELIBERATE SPEC VIOLATION". What is it? It turns out that the code of the old CSC compiler, due to bugs or some kind of misunderstanding, in some places violates the C # specifications. At the same time, Roslyn did not plan to make any changes that could break something, and so we got a new compiler, in some places the developers deliberately violated the C # spec and documented it as a deliberate spec violation :) Link .
I understand that the backward compatibility of the compiler and its API are different topics, but my example shows a team mentality well. I myself have contributed something to Roslyn and I can say that one of the most tedious aspects of code review is the amount of attention that is given to the analysis of each “public” API - precisely because it will be supported by Roslyn for a long time. So honestly, I wouldn’t worry about backward compatibility.
JUG.ru Group: How did you even come to realize that you started to explore the Roslyn API? What kind of problems did you originally want to solve?
Filip W: Initially I got into the Roslyn community because of working with scripts, we did the Scriptics project, one of those projects that helped us shape this whole story with scripts in C # 10 years later. Then I got into the OmniSharp project, which adds intellisense and C # language services to editors like emacs, vim or Atom. Although of course the largest and most recognizable "consumer" of OmniSharp in the .NET community is Visual Studio Code. There I started developing tools for code analysis, refactoring, and many other IDE-level language features.
JUG.ru Group: Tell me, what will happen with static code analysis in the near future? What should we expect the next 1-3-5 years?
Filip W: I think we will see a lot of “live” diagnostics. Josh Varty, one of my friends, built the coolest addon to Visual Studio called (Surprise!) Alive , which executes blocks of your source code and instantly tells you how your method or cycle will work, and also warns about errors that may occur. occur in runtime. All this is beyond static or semantic code analysis, everything is built on the basis of Roslyn.
So in general, in my opinion, we will encounter more and more advanced analysts, such as finding references to null through symbolic calculations. At the moment, the community still just understands the opportunities offered by Roslyn. In addition, I hope to see a more tight integration of Roslyn analyzers in third-party tools, such as OmniSharp or Resharper. Such analyzers already exist for Visual Studio Code, but their work is still far from ideal.
JUG.ru Group: Thank you, Philip, see you on DotNext!
Filip will give a presentation on “Building code analysis tools with the .NET Compiler Platform (Roslyn)” at the upcoming conference in St. Petersburg, on the same stage with Jon Skeet, Sasha Goldshtein and other MVPs. Details about speakers and reports are available on the DotNext 2017 Piter website .
PS We remind you that early registration is valid until the end of February and so far you can register, saving a couple of thousand .
To fix this, we interviewed Filip W, Microsoft MVP, the contributor to Roslyn, and simply one of the world's most popular ASP.NET bloggers. Why Filip thinks that changes in the new C # can go unnoticed, why write your own code analyzers, and also why scripting in C # is better than any scripting language?JUG.ru Group: Philip, let's start with warming up. ASP.NET Core is now changing a lot. How do you feel about the changes as a developer working with the platform?
')
Filip W: Of course, the pioneers experienced many problems: postponement, hell with versioning, name changes, problems with tools, inconsistent system of working with projects and much more, up to changes in the .NET Standard concept itself. Can you do better? Definitely yes, but in retrospect everything always looks simple and clear.
If to speak as a whole, absolutely exactly the changes are happening for the better. Just think, a few years ago ASP.NET worked only under Windows and only under IIS. In addition, it was based on System.Web.dll, which was added to each HTTP request by a ridiculous overhead (29Kb on average). Today, ASP.NET Core, according to benchmarks , is one of the top five best-performing web frameworks on Linux. From this point of view, the platform has undoubtedly gone through an incredible transformation.
JUG.ru Group: So you already wrote .NET applications under Linux? Tell me how things are with the stability of such decisions? Is the platform ready for production?
Filip W: Yes, many of my new projects are currently running on Docker on Debian-based systems. I ran into some problems with platform-specific code, such as cryptography, or with strange deadlocks appearing here and there, but on the whole, everything suits me. And of course, the benefits of managing the entire platform via Docker Swarm are impressive.
In fact, we are trying to develop cross-platform .NET code no matter which OS the project is deployed to. As a result, most of our projects have build agents for Windows, macOS and Linux. Thus, I can develop something on my Mac and be able to deploy it at least in Docker, at least in the Azure Web App with the guarantee that everything will work correctly.
JUG.ru Group: What about C #? In version 7.0, we will have tuples, pattern matching, and many other features. Will these innovations be useful for you, as a developer?
Filip W: In general, as in the case of C # 6.0, the changes are minor, so it is likely that many developers in their daily work will not notice the transition to the new version. For me personally, tuples will definitely be useful, since in the current form they are very poorly implemented. I hope this will help drastically reduce the number of auxiliary classes that we are facing now, when a developer is forced to create a new class to deserialize or read one or two fields from the database.
I'm a little upset that the pattern-matching syntax will not be based on expression-ah. Instead, there will be an emphasis on is and switch, however, I understand the rationality of the fact that innovations come step by step. In addition, more expressive elements help to write concise code, and C #, as we know, can be very “wordy”, so such changes are also for the better.
C # vs Powershell - 1: 0
JUG.ru Group: In the past DotNext you talked about scripting under C # . How do you think the report went? Is such a scenario using C # among .NET developers?
Filip W: Oh, I got an incredible audience response! I think scripting is one of the coolest sides of Roslyn, because it provides access to a lot of interesting user cases that were previously inaccessible in the .NET ecosystem. Of course, earlier it was possible to use Powershell, but the ability to write scripts in C # is quite another, considering how close it is to .NET developers. Now you can see a sharp increase in the use of scripts in C # in commercial projects: they implemented Azure Functions, extensions for games and much more. Add to this language services and support for intellisense / debugging for C #, which can be obtained in some lightweight editor, such as VS Code, and you get a very pleasant development process. It's funny that C #, being a non-script language, got such a powerful environment that hardly any of the scripting languages ​​can argue with it in terms of productivity.
In Moscow, in the discussion area, we spent almost two hours discussing the difficulties and ways of using C # scripts: for security, memory management, application expansion (script-based plug-in systems), and even a remote REPL for managing executable processes. It was cool!
Develop your own code inspections under Roslyn
JUG.ru Group: In addition to scripting, you also do static code analysis. Tell me, who may need to develop their own analyzer, given that there are VS and Resharper on the market?
Filip W: Our own analyzer is usually needed by timlids, which deal with code review and are generally responsible for the quality of the code in the team. Here it is important to understand that in the development process we are faced with some of our own problems and roughness, relevant only in the context of our project. Both Resharper and VS are universal tools designed for a wide audience, but what if you need to ensure that a particular pattern is used or the code matches your corporate guidelines? For example, establish class / variable naming rules, make sure that your internal API is used only as it was intended, that the code is documented in accordance with your standards, or that HTTP endpoints are developed in accordance with the established standard. Sometimes there are also strange things - I somehow worked in a project where at the compiler level it was forbidden to use tabs and # region-directives.
However, even if you forget about writing your own analyzer, it is important to understand how they work “under the hood”. As in other areas of programming, even if you don’t get your hands on writing your analyzer, it’s very useful to understand the principles that underlie them, as well as how the compiler API works, ensuring the operation of the code analyzer.
JUG.ru Group: Speaking of the compiler, which Roslyn Compiler API made your life easier compared to the previous one?
Filip W: Is this a trick question? In fact, the old compiler did not allow doing anything except feeding the code to it, and getting DLL / EXE files at the output. So for me the most important thing at Roslyn is that this is a real ompiler-as-a-Service, where each step of the pipeline has an external API that can be used in its own way. It is also surprising that before Roslyn there was no official C # AST library (only third-party options could be found).
JUG.ru Group: By the way, what about backward compatibility? What is the probability that my samopisny analyzer will fall apart on the next release of Roslyn?
Filip W: Well, the fact that the Roslyn team pays great attention to backward compatibility, I know for sure! If you delve into the compiler code, you can find incredible examples of this. For example, if searching in the source code of the compiler, you can find the lines "DELIBERATE SPEC VIOLATION". What is it? It turns out that the code of the old CSC compiler, due to bugs or some kind of misunderstanding, in some places violates the C # specifications. At the same time, Roslyn did not plan to make any changes that could break something, and so we got a new compiler, in some places the developers deliberately violated the C # spec and documented it as a deliberate spec violation :) Link .
I understand that the backward compatibility of the compiler and its API are different topics, but my example shows a team mentality well. I myself have contributed something to Roslyn and I can say that one of the most tedious aspects of code review is the amount of attention that is given to the analysis of each “public” API - precisely because it will be supported by Roslyn for a long time. So honestly, I wouldn’t worry about backward compatibility.
JUG.ru Group: How did you even come to realize that you started to explore the Roslyn API? What kind of problems did you originally want to solve?
Filip W: Initially I got into the Roslyn community because of working with scripts, we did the Scriptics project, one of those projects that helped us shape this whole story with scripts in C # 10 years later. Then I got into the OmniSharp project, which adds intellisense and C # language services to editors like emacs, vim or Atom. Although of course the largest and most recognizable "consumer" of OmniSharp in the .NET community is Visual Studio Code. There I started developing tools for code analysis, refactoring, and many other IDE-level language features.
JUG.ru Group: Tell me, what will happen with static code analysis in the near future? What should we expect the next 1-3-5 years?
Filip W: I think we will see a lot of “live” diagnostics. Josh Varty, one of my friends, built the coolest addon to Visual Studio called (Surprise!) Alive , which executes blocks of your source code and instantly tells you how your method or cycle will work, and also warns about errors that may occur. occur in runtime. All this is beyond static or semantic code analysis, everything is built on the basis of Roslyn.
So in general, in my opinion, we will encounter more and more advanced analysts, such as finding references to null through symbolic calculations. At the moment, the community still just understands the opportunities offered by Roslyn. In addition, I hope to see a more tight integration of Roslyn analyzers in third-party tools, such as OmniSharp or Resharper. Such analyzers already exist for Visual Studio Code, but their work is still far from ideal.
JUG.ru Group: Thank you, Philip, see you on DotNext!
Filip will give a presentation on “Building code analysis tools with the .NET Compiler Platform (Roslyn)” at the upcoming conference in St. Petersburg, on the same stage with Jon Skeet, Sasha Goldshtein and other MVPs. Details about speakers and reports are available on the DotNext 2017 Piter website .
PS We remind you that early registration is valid until the end of February and so far you can register, saving a couple of thousand .
Source: https://habr.com/ru/post/322226/
All Articles