Showing posts with label .NET Core. Show all posts
Showing posts with label .NET Core. Show all posts

14/05/2018

How to use Roslyn with .NET Core?

Home

Title: Baths of Caracalla in Rome, Source: own resources, Authors: Agnieszka and Michał Komorowscy

When we started PlatformX project, we were using full .NET Framework and it was natural to use Roslyn in order to read and analyse C# code. I have to admit that Roslyn, despite some initial problems (see other posts about Roslyn), managed to do the job. However, later on we decided to migrate PlatformX to .NET Core. There were a few reasons behind this decision:
  • We anticipated that in future we may want move to Linux server for example to reduce costs.
  • .NET Core is faster. To give you an example. After migration builds turned out to be 1.7 times faster and tests 2.6 times faster!
  • Before migration we had to support 2 versions of our infrastructure libraries (.NET Framework + .NET Core) what was a little bit cumbersome. Now we support only one.
  • If we had waited, we would have spent more time on the migration later.
Despite all these advantages the migration to .NET Core meant a problem with using Roslyn. This problem is called MsBuildWorkspace. It is the class that allows you to point a solution or a project, read it and then analyse it a file after a file. Unfortunately MsBuildWorkspace is not supported in .NET Core. I think that the main issue is that under the hood it uses MS Build which is not cross-platform.

Because nowadays .NET Core projects can actually reference full .NET Framework libraries (of course it kills portability), firstly we simply tried to do so. But without much success. MsBuildWorkspace simply cannot handle .NET Core projects. The actual effect was that according to MsBuildWorkspace there were no files in a project being analysed.

Fortunately, the rescue came from Buildalyzer project which does exactly what MsBuildWorkspace should do and it works like a charm. Here is how we use Buildalyzer:
var sb = new StringBuilder();
var writer = new StringWriter(sb);

var manager = new AnalyzerManager(solutionPath,
   new AnalyzerManagerOptions
   {
      LogWriter = writer
   });

foreach (var prj in manager.Projects.Values)
{
   // GetWorkspace returns Microsoft.CodeAnalysis.AdhocWorkspace which can be used with Roslyn
   var workspace = prj.GetWorkspace();

   // Starting from here the code does not depend on Buildalyzer
   var sln = workspace.CurrentSolution;

   await AnalyzeProject(sln.Projects.First());
}

writer.Close();

_logger.Write(sb.ToString());
As to AnalyzeProject method, it is responsible for analyzing all files in the project. What is important it DOES NOT depend on Buildalyzer at all. I really didn't have to change a line after switching from MsBuildWorkspace to Buildalyzer and it is amazing. Just a few lines of extra code and you can take all advantages of Roslyn in .NET Core projects in order to analyse other .NET Core projects.

*The picture at the beginning of the post comes from own resources and shows Baths of Caracalla in Rome.

22/09/2017

SpecFlow + .NET Core = problems

Home



Since I started using SpecFlow acceptance tests, I think that they are simply great. If I had to select whether to write only unit tests or only acceptance tests, I would select the latter. Nonetheless, there is one important problem with SpecFlow.