Azure, C#

The moment I came to play with .NET Standard 2.0 part 2!

1 min read

So I’ve been on a mission to get all my pieces from my last post to work.

While configuring my Continuous Integration (CI) pipeline for my bot, I’ve came across an error that made my CI build fail:

What? My project compiles fine on my computer and I thought that .NET Framework 4.7.1 had built-in support for .NET Standard 2.0.

Well according to this GitHub issue something ain’t quite right yet. Adding the reference <Reference Include=”netstandard” /> directly into the csproj fixes the issue (thanks techaimail!)

Azure Functions 2

Azure functions 2 (using the .NET Standard 2 framework) is still in preview (beta). So when you deploy your function through your CI/CD pipeline, make sure to go in the Application Settings of your function app and set the FUNCTIONS_EXTENSION_VERSION value to beta. I spent a good hour figuring out why my function would not start. The joy!

When it comes to accessing your connection string, the suggested way is to use the System.Configuration.ConfigurationManager class to access your connection string from either the local.settings.json or the connection strings that is set in the function app Connection strings.

Knowing this, I add the package System.Configuration.ConfigurationManager from NuGet and setup my code to access the connection string through ConfigurationManager.ConnectionStrings[“Key”].ConnectionString.

While debugging my function locally, I get the following exception:

This issue has been documented on GitHub. Microsoft say they are working to move to the ASP.NET Core configuration model.

Jon Gallant made a great post about how you can integrate this. Check it out!

A workaround is to use environment variables. By adding a ConnectionString Application Settings variable in the function app Application Settings, I was able get the connection string by accessing APPSETTING_ConnectionString environment variable when in production or ConnectionStrings:DefaultConnection environment variable when developing locally (this is set in the local.settings.json)

This is not bad for now! I will continue to update you guys on my project and my findings. Stay tuned.