VS Code – forcing partial IntelliSense support for Cake scripts

1. Introduction

I’ve been using Cake for quite some time now, and I really like this tool, however the more complex my build scripts are, the more painful lack of IntelliSense is. Inspired a bit by this post, I decided to see what it takes to enable at least partial IntelliSense for Cake scripts in Visual Studio Code.

2. Investigation

The proper way of providing the code completion for Cake scripts would probably be a plugin to Omnisharp-Roslyn, as Cake script is basically a valid c# snippet. Unfortunately, at this moment Omnisharp-Roslyn doesn’t have plugin infrastructure ready, that is why I decided to go with a bit different path. As you might or might not be aware, VS Code already supports csx files, so if you add an empty project.json file (by empty I mean file with empty JSON object) to your build directory and change extension of your scripts to csx, you will immediately get a C# syntax highlighting and some IntelliSense support. Sadly this will not provide code completion for Cake method aliases. The reason why it fails on that is the fact that the Cake alias is ICakeContext extension method

but you use it as it was written as

The Cake engine generates additional alias overloads during script compilation, and as these overloads exist only on runtime, VS Code just can’t “see” them.

3. My approach

Having in mind the way Cake works I decided to write an application which would be able to take any Cake or Cake add-in and produce a library containing proper alias overloads. For instance, if original Cake method looks as follows

the application will rewrite it into

The algorithm looks more or less like that

  • Retrieve Cake or Cake add-in via NuGet
  • Scan an assembly and find all classes containing alias methods
  • Use CSharpCodeGenerationService to generate metadata for Cake alias methods
  • Parse generated code with Roslyn and produce SyntaxTree
  • Append Metadata suffix to classes containing alias method
  • Remove ICakeContext parameter from alias method
  • Generate dummy body for methods which require that (methods which have return type or which have out parameters)
  • Update xml documentation
  • Compile generated code and produce dll

There is no point of doing more detailed description in here so if you want to take a closer look here is source code.

4. Generating metadata libraries

Before we start “hacking” VS Code to have IntelliSense, we have to prepare metadata libraries which will contain all necessary Cake alias overloads. In order to do that grab the application from NuGet and generate Cake.Common and Cake.Core metadata libraries. The simplest way of doing it is to run these commands

As a result, the application will produce following files:

  • Cake.CommonMetadata.dll
  • Cake.CommonMetadata.xml
  • Cake.CoreMetadata.dll
  • Cake.CoreMetadata.xml

5. Enabling IntelliSense in VS Code

Having our metadata libraries prepared now we can adjust our build scripts to have code completion in VS Code. Here are the steps:

  • Add project.json file with empty JSON object into your build directory.
  • Change extension of all your build scripts to csx.
  • Copy metadata libraries into your Build directory.
  • Create imports.csx file. This is the file which contains all original namespace imports. It may look as follows
  • Create metadataimports.csx file. This is the file which contains metadata namespaces imports and loads Cake and metadata references.Each original Cake alias class has corresponding metadata class with Metadata suffix, for instance
    Cake.Common.ArgumentAliases -> Cake.Common.ArgumentAliasesMetadata
    Cake.Common.EnvironmentAliases -> Cake.Common.EnvironmentAliasesMetadata
  • Load imports.csx to your build.csx file via
  • Run VS Code install ms-vscode.csharp 1.7.0, open Build directory and write your build script with IntelliSense support
  • Before running the script remember to comment outfrom imports.csx file
  • Run the build

I do realize this is quite convoluted explanation so in case of any troubles take a look at my build

6. Known issues

  • Cake.Intellisense can only generate metadata libraries for a standard .NET frameworks, it will fail if you try to create metadata targeting .NETStandard or .NET Core framework
  • Due to some breaking changes in Omnisharp-Roslyn scripting support, IntelliSense will only work with Omnisharp 1.7.0

7. Summary

This approach is just a temporary solution. As you can see, it requires significant amount of work to have a code completion in VS Code. I believe that once Omnisharp-Roslyn has proper plugin support it should be possible to write some kind of custom IntelliSense provider for Cake scripts. There are already people who forked Omnisharp-Roslyn and play around with that, so we just have to wait for something better than this solution.

VS Code – forcing partial IntelliSense support for Cake scripts

Downgrading Visual Studio Code extension

1. Introduction

For time to time when you update Visual Studio Code’s extension you realize that there were some breaking changes you don’t like or the extension has a bug which prevents you from using it. Usually, in this kind of situations, you would like to just go back to the version you were using previously rather than stop using the extension at all. Unfortunately, VSCode doesn’t give us an option to install a specific version of the extension for now. Luckily there is an easy way of doing that manually.

2. Installation

Let’s assume that I would like to downgrade C# plugin from newest version (1.8.1 at the moment) to 1.7.0. First of all, we have to uninstall current extension. As there as some issues of doing that via command line, just do it from VSCode by clicking on uninstall button in extension screen.
Initial
In the next step we have to download proper extension’s version using vsassets api. The url pattern looks as follows

In my case, the variables looks as follow

  • ${publisher} – ms-vscode
  • ${extension_name} – csharp
  • ${version} – 1.7.0

and entire url can be rewritten as

Having the link prepared we can paste it into browser address bar and download the extension. Once the file is downloaded, run VSCode, hit CTRL+SHIFT+P, type vsix in command line and choose

vsix
Select the file you’ve just downloaded and restart editor after installation. From now on you can use older version of your favorite extension.
after

Downgrading Visual Studio Code extension

Asp.NET Core – populating IOptions<T> from external data source

1. Introduction

In ASP.NET Core web.config is no longer a proper place for storing application settings. New framework introduces the concept of a json based configuration and the default file which stores the settings now is appsettings.json. Here is a quick tutorial how to use new features.

2. Reading configuration

Let’s assume that our appsettings.json file looks as follows.

Thanks to ConfigurationBuilder we can parse this config and later on materialize sections or entire file into strongly typed configuration classes. Let’s say we want to parse AvailabilitySearchOptions node to following class

We can achieve that with following steps. First of all, we need to read entire configuration

And in the next step we have to register IOptions<AvailabilitySearchOptions> in the container using services.Configure<TOptions>(IConfiguration section) method

Note Configuration.GetSection(“AvailabilitySearchOptions”) passed as argument to services.Configure method.
From now on we can access AvailabilitySearchOptions settings via IOptions<AvailabilitySearchOptions> interface, which you can easily inject into your classes.

3. Populating IOptions<T> from external data source

From time to time, reading configuration just from JSON file might not be enough and for instance you would like to add additional configuration read from some external data source. Fortunately you don’t have to resign from the IOptions<T> class as it is possible to read additional data for literally any other source thanks to IConfigureOptions<T> class. All we have to do is to create a setup class which implements IConfigureOptions<T> interface

And then registering this class in our container

From now on, when value of IOptions<AvailabilitySearchOptions> is accessed for very first time, Configure method from AvailabilitySearchOptionsSetupService will be called and you will be able to set additional values for your settings. Note that values from appsettings.json will already be there.
In addition, it is possible to have multiple implementations of IConfigureOptions<T> so if you want your setup to be split into multiple classes you are good to go.
multiple
Source code for this post can be found here

Asp.NET Core – populating IOptions<T> from external data source

XUnit – sharing test data across assembly

1. Introduction

XUnit provides two ways of sharing data between tests – ICollectionFixture and IClassFixture. The first one allows you to shared context across collections and the second one across test classes. I’ve already had a couple of cases in which these fixtures were not enough. Basically, I wanted to share data between all tests in given assembly – without worrying in which test class or test collection given test is. In these circumstances, I’ve usually used some kind of old fashioned singleton or custom TestFrameworkExecutor. I’ve never liked those solutions, fortunately recently I’ve come across a nice little library – xunit.assemblyfixture.

2. Usage

Xunit.assemblyfixture allows you to share data between tests in given assembly via IAssemblyFixture interface. The usage is basically the same as in other XUnit’s fixtures. All we have to do is to create a class which instance we want to share with other tests

And then create test classes which implement IAssemblyFixture interface. If we want to have access to the fixture from the tests, we can inject instance of TFixture via constructor

Xunit.assemblyfixture fixture will ensure that given test class is shared via all the tests and is initialized only once.
Shared
If you want to share multiple classes across the assembly, you can, of course, use IAssemblyFixture multiple times.

3. Visual Studio 2017 – XUnit beta tests runners

As for now VS 2017 RC requires beta runners of XUnit in order to run our unit tests. xunit.assemblyfixture seems not to cooperate with them smoothly. However, there is a simple workaround to fix that. All we have to do is to add the following attribute to our test project

And from now on, XUnit correctly can inject assembly fixtures into our test classes

Source code for this post can be found here

XUnit – sharing test data across assembly

ASP.NET Core – tracking flow of requests with NLog

1. Introduction

A while ago I wrote an article about using MappedDiagnosticsLogicalContext for tracking request flow in your application. As we are moving our project to ASP.NET Core, I wanted to keep that functionality in place. Unfortunately, MDLC layout renderer is not available in that framework anymore(when targeting .NET Core). Luckily, there are two other renderers which can be used as a replacement:

  • aspnet-traceidentifier
  • aspnet-item

2. Configuring NLog

Before I dig into details of layout renderers mentioned above, we have to configure ASP.NET Core to use NLog as a logger. First of all, we need to grab NLog.Web.AspNetCore NuGet package. Once the package is installed we have to manually add NLog.config to the project (the file won’t be added automatically by NuGet installer). The next step is to configure NLog with our config, then configure NLogWeb and finally register NLog in LoggingFactory. All of these steps should be done in Startup class.

The final step required for NLog to work is to register HttpContextAccessor in IoC container of your choice. If you use the build one, you can do it like that

3. Using aspnet-traceidentifier renderer

Aspnet-traceidentifier layout renderer allows you to obtain value of TraceIdentifier property from current HttpContext. TraceIdentifier is basically unique id which identifies the request. The renderer can be used as follows

From now on (without any additional configuration) every log entry logged (once HttpContext is created), will contain TraceIdentifier.

4. Using aspnet-item renderer

If for some reasons we don’t like to use TraceIdentifier as our CorrelationId, we can leverage aspnet-item renderer, which basically allows you to read data from HttpContext.Items collection. However in that case, we are responsible for providing and storing unique identifier of request in HttpContext.Items. Fortunately it is pretty straightforward to do with custom middleware.

Of course we have to also use this middleware in our application so we have to add following line

in configure method of our Startup class. Having all the pieces in place, now we can append CorrelationId read from HttpContext.Items to our log entries with following configuration

From now on, CorrelationId will be automatically added to our log entries

6. It works in multithreading scenarios

If you take a closer look at logs presented above, you will see that both of the renderers can log proper CorrelationId/TraceId regardless of the thread from which the logger was called. This is possible thanks to implementation of HttpContextAccessor which uses AsyncLocal under the hood, which allows you to persist data across threads.

Source code for this post can be found here

ASP.NET Core – tracking flow of requests with NLog